计算机网络

典型回答 Cookie、Session和Token是用于在Web应用程序中管理用户状态和身份验证的技术。因为在Web应用中，HTTP的通信是无状态的，每个请求都是完全独立的，所以服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。 Cookie是由服务器发送给用户浏览器的小型文本文件，存储在客户端的浏览器中。它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。服务器可以读取Cookie并使用其中的信息来进行识别和个性化处理。 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的。cookie 是不可跨域的，并且每个域名下面的Cookie的数量也是有限的。 Session是在服务器端创建和管理的一种会话机制。当用户首次访问网站时，服务器会为该用户创建一个唯一的Session ID，通常通过Cookie在客户端进行存储。会话标识符在后续的请求中用于标识具体是哪个用户。通常情况下，session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中。 Cookie 和 Session 的区别主要有以下几个 存储位置不同： Session 是存储在服务器端的，Cookie 是存储在客户端的。 安全性不同：因为Session存储在服务器端，所以Session 比 Cookie 安全。 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。 有了cookie和session之后，基本可以实现用户的各种验证、鉴权及身份识别了。但是，还是有一些场景中，不是特别适合这两种方案，或者说这两种方案的话还不够，那么就需要token上场了。 Token也是一种用于用户身份鉴权的手段。他其实是一种代表用户身份验证和授权的令牌。在Web应用程序中，常用的身份验证方案是基于令牌的身份验证（Token-based Authentication）。当用户成功登录时，服务器会生成一个Token并将其返回给客户端。客户端在后续的请求中将Token包含在请求头或请求参数中发送给服务器。服务器接收到Token后，会进行验证和解析，以确定用户的身份和权限。Token通常是基于某种加密算法生成的，因此具有一定的安全性。 主要由以下几个场景： 1、跨域请求：Cookie是不支持跨域的，当在不同的域名之间进行通信时，使用Token可以更方便地在跨域请求中传递身份验证信息，而不受Cookie限制。 2、分布式场景：Session是存储在服务器上的，但是随着现在很多都是集群部署，这就使得Session也需要实现分布式Session，而如果能用Token的话，就可以不用这么复杂。 ✅怎么实现分布式Session？ 3、API交互：当我们使用浏览器访问后端服务的时候，可以用cookie和session，但是如果是API调用，比如Dubbo交互，就没办法做cookie的存储和传递了，而使用Token是常见的身份验证方式。客户端通过提供Token来证明其身份，并获得对受保护资源的访问权限。 4、跨平台应用程序：Token可以轻松地在不同的平台和设备之间共享和传递，而无需依赖特定的会话机制或Cookie支持。 5、前后端分离项目：现在很多项目都是前后端分离的了，这种项目中，前端和后端之间通过API的方式交互，这种的话用Token也会更加方便一些。 总之，因为Cookie和Session存在各种限制，所以Token也是目前常见的身份验证和状态管理方式，它具有更大的灵活性和适用性，特别适用于现代的应用程序架构和需求。它提供了一种无状态、可扩展和安全的身份验证和授权机制。 而且，有了token之后，还可以基于Token做防重检测。 ✅不用redis分布式锁， 如何防止用户重复点击？ 扩展知识 不用Cookie如何实现Session Cookie是实现Session的主要手段，但是有些场景中是不能使用的，比如有的浏览器可以禁用cookie，或者某些网站的cookie数量也有限制，而且跨域场景也不能用cookie 。所以，如果不能用cookie，那么改如何实现session呢？ 首先就是可以将Session ID作为查询参数附加在URL中。例如，http://www.hollischuang.com/page?sessionid=hollis666。服务器会解析URL中的Session ID，并使用它来识别和恢复用户的会话状态。这种方式在某些情况下可以工作，但也存在一些安全性和隐私方面的考虑。 其次，也可以在页面的在表单中添加一个隐藏字段来存储Session ID。当用户提交表单时，会话标识符会随着请求一起发送到服务器。服务器接收到请求后，从隐藏字段中提取Session ID，并使用它来识别和恢复会话状态。这种方法通常用于Web应用程序中的表单提交和POST请求。 ...

典型回答 TCP队头阻塞 HTTP/2虽然解决了HTTP队头阻塞的问题****。HTTP/2仍然会存在TCP队头阻塞的问题，那是因为HTTP/2其实还是依赖TCP协议实现的。 TCP传输过程中会把数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。 但是如果其中的某一个数据包没有按照顺序到达，接收端会一直保持连接等待数据包返回，这时候就会阻塞后续请求。这就发生了TCP队头阻塞。 HTTP/1.1的管道化持久连接也是使得同一个TCP链接可以被多个HTTP使用，但是HTTP/1.1中规定一个域名可以有6个TCP连接。而HTTP/2中，同一个域名只是用一个TCP连接。 所以，在HTTP/2中，TCP队头阻塞造成的影响会更大，因为HTTP/2的多路复用技术使得多个请求其实是基于同一个TCP连接的，那如果某一个请求造成了TCP队头阻塞，那么多个请求都会受到影响。 TCP握手时长 一提到TCP协议，大家最先想到的一定是他的三次握手与四次关闭的特性。 因为TCP是一种可靠通信协议，而这种可靠就是靠三次握手实现的，通过三次握手，TCP在传输过程中可以保证接收方收到的数据是完整，有序，无差错的。 但是，问题是三次握手是需要消耗时间的，这里插播一个关于网络延迟的概念。 网络延迟又称为 RTT（Round Trip Time）。他是指一个请求从客户端浏览器发送一个请求数据包到服务器，再从服务器得到响应数据包的这段时间。RTT 是反映网络性能的一个重要指标。 我们知道，TCP三次握手的过程客户端和服务器之间需要交互三次，那么也就是说需要消耗1.5 RTT。 另外，如果使用的是安全的HTTPS协议，就还需要使用TLS协议进行安全数据传输，这个过程又要消耗一个RTT（TLS不同版本的握手机制不同，这里按照最小的消耗来算） 那么也就是说，一个纯HTTP/2的连接，需要消耗1.5个RTT，如果是一个HTTPS连接，就需要消耗3-4个RTT。 而具体消耗的时长根据服务器和客户端之间的距离则不尽相同，如果比较近的话，消耗在100ms以内，对于用户来说可能没什么感知，但是如果一个RTT的耗时达到300-400ms，那么，一次连接建立过程总耗时可能要达到一秒钟左右，这时候，用户就会明显的感知到网页加载很慢。 升级TCP是否可行？ 基于上面我们提到的这些问题，很多人提出来说：既然TCP存在这些问题，并且我们也知道这些问题的存在，甚至解决方案也不难想到，为什么不能对协议本身做一次升级，解决这些问题呢？ 其实，这就涉及到一个”协议僵化“的问题。 这样讲，我们在互联网上浏览数据的时候，数据的传输过程其实是极其复杂的。 我们知道的，想要在家里使用网络有几个前提，首先我们要通过运行商开通网络，并且需要使用路由器，而路由器就是网络传输过程中的一个中间设备。 中间设备是指插入在数据终端和信号转换设备之间，完成调制前或解调后某些附加功能的辅助设备。例如集线器、交换机和无线接入点、路由器、安全解调器、通信服务器等都是中间设备。 在我们看不到的地方，这种中间设备还有很多很多，一个网络需要经过无数个中间设备的转发才能到达终端用户。 如果TCP协议需要升级，那么意味着需要这些中间设备都能支持新的特性，我们知道路由器我们可以重新换一个，但是其他的那些中间设备呢？尤其是那些比较大型的设备呢？更换起来的成本是巨大的。 而且，除了中间设备之外，操作系统也是一个重要的因素，因为TCP协议需要通过操作系统内核来实现，而操作系统的更新也是非常滞后的。 所以，这种问题就被称之为”中间设备僵化”，也是导致”协议僵化”的重要原因。这也是限制着TCP协议更新的一个重要原因。 所以，近些年来，由IETF标准化的许多TCP新特性都因缺乏广泛支持而没有得到广泛的部署或使用！ 放弃TCP？ 上面提到的这些问题的根本原因都是因为HTTP/2是基于TCP实现导致的，而TCP协议自身的升级又是很难实现的。 那么，剩下的解决办法就只有一条路，那就是放弃TCP协议。 放弃TCP的话，就又有两个新的选择，是使用其他已有的协议，还是重新创造一个协议呢？ 看到这里，聪明的读者一定也想到了，创造新的协议一样会受到中间设备僵化的影响。近些年来，因为在互联网上部署遭遇很大的困难，创造新型传输层协议的努力基本上都失败了！ 所以，想要升级新的HTTP协议，那么就只剩一条路可以走了，那就是基于已有的协议做一些改造和支持，UDP就是一个绝佳的选择了。

典型回答 HTTP和HTTPS是两种协议，分别是Hypertext Transfer Protocol和HyperText Transfer Protocol Secure。 HTTPS还经常被称之为HTTP over SSL或者HTTP over TSL，HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。 他们的区别主要由以下几个方面： 安全性: HTTP: HTTP是明文传输的，这意味着数据在传输过程中不加密，容易受到中间人攻击。敏感信息，如密码和信用卡号，如果通过HTTP传输，可能会被窃取。 HTTPS: HTTPS使用SSL（Secure Sockets Layer）或其继任者TLS（Transport Layer Security）来加密数据传输，使数据在传输过程中加密，更难被中间人攻击窃取。 URL: HTTP: HTTP的URL以http://开头 HTTPS: HTTPS的URL以https://开头 证书: HTTP: HTTP不需要使用数字证书。 HTTPS: HTTPS需要使用数字证书，这个证书由受信任的第三方机构（如CA，Certificate Authority）颁发，用于验证网站的身份。 默认端口: HTTP: 默认端口为80。 HTTPS: 默认端口为443。 性能: HTTP: 由于不需要加密和解密数据，HTTP的性能通常比HTTPS更高。这在某些情况下可以使HTTP成为更好的选择，尤其是对于不涉及敏感信息的静态内容传输。 HTTPS: HTTPS需要进行加密和解密操作，这会增加一些计算开销，但现代计算机和服务器通常能够很好地处理这种负担。 扩展知识 TLS VS SSL TLS（Transport Layer Security）和 SSL（Secure Sockets Layer）都是加密通信协议，用于在计算机网络上保护数据传输的安全性。 SSL TLS 全称 Secure Sockets Layer Transport Layer Security 重要版本 SSL 1.0SSL 2.0SSL 3.0 TLS 1.0TLS 1.1TLS 1.2TLS 1.3 使用情况 SSL各个版本都存在安全漏洞，目前用的比较少 TLS 1.2和TLS 1.3是目前最广泛使用的版本，因为它们提供更高的安全性。 性能 TLS的性能通常比SSL更好，尤其是TLS 1.2和TLS 1.3版本，因为它们引入了更有效的加密算法和协议优化。

典型回答 HTTP/2主要是解决HTTP中存在的效率问题。它主要引入了二进制分帧、多路复用、header压缩、以及服务端推送的新特性，大大的提升了效率。 而且，在HTTP/2中还解决了一个重要的问题，那就是HTTP的队头阻塞问题。 扩展知识 HTTP 超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。设计HTTP最初的目的是为了提供一种发布和接收HTML页面的方法。通过HTTP或者HTTPS协议请求的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识。 HTTP 协议是以 ASCII 码传输，基于请求与响应模式的、无状态的，建立在 TCP/IP 协议之上的应用层规范。。它不涉及数据包（packet）传输，主要规定了客户端和服务器之间的通信格式，默认使用80端口。 HTTP协议主要的版本有3个，分别是HTTP/1.0、HTTP/1.1和HTTP/2。HTTPS是另外一个协议，简单讲是HTTP的安全版。 HTTP/1.0 1996年5月，HTTP/1.0 版本发布，为了提高系统的效率，HTTP/1.0规定浏览器与服务器只保持短暂的连接，浏览器的每次请求都需要与服务器建立一个TCP连接，服务器完成请求处理后立即断开TCP连接，服务器不跟踪每个客户也不记录过去的请求。 请注意上面提到的HTTP/1.0中浏览器与服务器只保持短暂的连接，连接无法复用。也就是说每个TCP连接只能发送一个请求。发送数据完毕，连接就关闭，如果还要请求其他资源，就必须再新建一个连接。 我们知道TCP连接的建立需要三次握手，是很耗费时间的一个过程。所以，HTTP/1.0版本的性能比较差。现在，随便打开一个网页，上面都会有很多图片、视频等资源，HTTP/1.0显然无法满足性能要求。 HTTP/1.1 为了解决HTTP/1.0存在的缺陷，HTTP/1.1于1999年诞生。相比较于HTTP/1.0来说，最主要的改进就是引入了持久连接。所谓的持久连接就是：在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟。 引入了持久连接之后，在性能方面，HTTP协议有了明显的提升，基本可以用于日常使用，这也是这一版本一直延用至今的原因。当然还是有些力不从心的，后面会详细介绍。 关于HTTP/1.0和HTTP/1.1还有些其他区别，这里就不展开介绍了。网上也很多资料，可以自行查阅。 SPDY 虽然，HTTP/1.1在HTTP/1.0的基础上提供了持久连接，提升了很大的效率，但是，还是有很大的提升空间。 正所谓时势造英雄，正是因为HTTP存在着诸多不足，所以，才诞生了SPDY。2009年，谷歌公开了自行研发的 SPDY 协议，主要解决 HTTP/1.1 效率不高的问题。它的设计目标是降低 50% 的页面加载时间。SPDY主要提供了以下功能（后文介绍HTTP2的时候再详细介绍）： 多路复用（multiplexing）。多个请求共享一个tcp连接。 header压缩。删除或者压缩HTTP头 服务端推送。提供服务方发起通信，并向客户端推送数据的机制。 SPDY位于HTTP之下，TCP和SSL之上，这样可以轻松兼容老版本的HTTP协议。 实际上在 HTTP2 提出来之前，SPDY 流行了很长一段时间。当下很多著名的互联网公司都在自己的网站或 APP 中采用了 SPDY 系列协议（当前最新版本是 SPDY/3.1），因为它对性能的提升是显而易见的。主流的浏览器（谷歌、火狐、Opera）也都早已经支持 SPDY，它已经成为了工业标准。HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2。 ...

典型回答 “墙”在这里指的是一种网络屏蔽机制，它通过对互联网流量进行控制，阻止用户访问特定的外部网站或服务。 “墙”一般通过以下几种方式屏蔽和干扰网络流量： IP封锁：屏蔽某些IP地址或服务器，使得用户无法访问相关的网络资源。 DNS污染：通过改变域名解析结果，导致用户访问特定网站时无法正确找到目标服务器。 ✅什么是DNS污染？DNS劫持？ DNS污染是指当一个DNS服务器被恶意修改或替换，导致该服务器不再返回正确的DNS记录，而是返回错误的记录，从而将用户错误地导向到恶意站点。 梯子是啥不用介绍了，梯子的实现方式主要是正向代理。 ✅什么是正向代理和反向代理？ 有时候，用户想要访问某国外网站，该网站无法在国内直接访问，但是我们可以访问到一个代理服务器，这个代理服务器可以访问到这个国外网站。这样呢，用户对该国外网站的访问就需要通过代理服务器来转发请求，并且该代理服务器也会将请求的响应再返回给用户。这个上网的过程就是用到了正向代理。 所以，正向代理，其实是”代理服务器”代理了”客户端”，去和”目标服务器”进行交互。 通过正向代理服务器访问目标服务器，目标服务器是不知道真正的客户端是谁的，甚至不知道访问自己的是一个代理。

典型回答 CDN是Content Delivery Network的缩写，翻译成内容分发网络（这个中文名我一直记不住），它主要是通过将内容存储在全球各地的边缘节点上，以就近原则向用户提供内容。 **CDN可以做缓存是因为它在全球范围内部署了多个边缘节点，这些节点分布在不同的地理位置，靠近用户所在的区域。**当用户请求某个资源（例如网页、图片、视频等），CDN会根据用户的位置，将资源从最近的边缘节点提供给用户。 比如说我在内蒙古呼和浩特，我想要访问部署在上海的淘宝服务器，这时候发起一次请求的话，就需要从呼和浩特把请求发送到上海。那如果能够更近一点的区域快速拿到一些资源的话，就可以不用这么慢了。 那么CDN刚好是可以部署在很多地方的边缘节点，你比如说阿里云的CDN（非广告，哈哈哈），在全球拥有3200+节点。中国内地（大陆）拥有2300+节点，覆盖31个省级区域；中国香港、中国澳门、中国台湾、其他国家和地区拥有900+节点，覆盖70多个国家和地区。 如果很多静态资源可以放到CDN上面，那么就可以就近的访问到CDN，然后快速的获取到这些静态的资源。 CDN具有广泛的应用场景，可实现图片小文件、大文件下载和视音频点播业务类型的存储，以实现加速的目的。 用户首次访问这些资源的时候，CDN会将资源从服务器获取到，并将其缓存到边缘节点上。当其他用户在同一地区请求相同的资源时，CDN会直接从边缘节点返回缓存的副本，而不必再次访问源服务器。这样可以减少网络延迟和带宽消耗，提高内容的传输速度和响应性能。

典型回答 我们知道，HTTP/2之所以"被弃用"，是因为他使用的传输层协议仍然是TCP，所以HTTP/3首要解决的问题就是绕开TCP。 ✅HTTP/2存在什么问题，为什么需要HTTP/3？ 那么如果研发一种新的协议，同样还是会因为受到中间设备僵化的影响，导致无法被大规模应用。所以，研发人员们想到了一种基于UDP实现的方式。 于是，Google是最先采用这种方式并付诸于实践的，他们在2013年推出了一种叫做QUIC的协议，全称是Quick UDP Internet Connections。 从名字中可以看出来，这是一种完全基于UDP的协议。 在设计之初，Google就希望使用这个协议来取代HTTPS/HTTP协议，使网页传输速度加快。2015年6月，QUIC的网络草案被正式提交至互联网工程任务组。2018 年 10 月，互联网工程任务组 HTTP 及 QUIC 工作小组正式将基于 QUIC 协议的 HTTP（英语：HTTP over QUIC）重命名为HTTP/3。 所以，我们现在所提到的HTTP/3，其实就是HTTP over QUIC，即基于QUIC协议实现的HTTP。 那么，想要了解HTTP/3的原理，只需要了解QUIC就可以了。 QUIC协议有以下特点： 基于UDP的传输层协议：它使用UDP端口号来识别指定机器上的特定服务器。 可靠性：虽然UDP是不可靠传输协议，但是QUIC在UDP的基础上做了些改造，使得他提供了和TCP类似的可靠性。它提供了数据包重传、拥塞控制、调整传输节奏以及其他一些TCP中存在的特性。 实现了无序、并发字节流：QUIC的单个数据流可以保证有序交付，但多个数据流之间可能乱序，这意味着单个数据流的传输是按序的，但是多个数据流中接收方收到的顺序可能与发送方的发送顺序不同！ 快速握手：QUIC提供0-RTT和1-RTT的连接建立 使用TLS 1.3传输层安全协议：与更早的TLS版本相比，TLS 1.3有着很多优点，但使用它的最主要原因是其握手所花费的往返次数更低，从而能降低协议的延迟。 那么，QUIC到底属于TCP/IP协议族中的那一层呢？我们知道，QUIC是基于UDP实现的，并且是HTTP/3的所依赖的协议，那么，按照TCP/IP的分层来讲，他是属于传输层的，也就是和TCP、UDP属于同一层。 如果更加细化一点的话，因为QUIC不仅仅承担了传输层协议的职责，还具备了TLS的安全性相关能力，所以，可以通过下图来理解QUIC在HTTP/3的实现中所处的位置。

2019年11月25日，负责英国、欧洲、中东和部分中亚地区互联网资源分配的欧洲网络协调中心（RIPE NCC）宣布，其最后的 IPv4 地址空间储备池在 11 月 25 日 UTC + 1 15:35 完全耗尽，所有 43 亿个 IPv4 地址已分配完毕。 其实，早在20世纪80年代后期开始，全球已经开始意识到这个问题将会发生。IPv6的研发及布署，主要就是为了解决这个问题。 什么是IPv4？ IPv4是Internet Protocol version 4的缩写，中文翻译为互联网通信协议（TCP/IP协议）第四版，通常简称为网际协议版本4。  IPv4使用32位（4字节）地址，因此地址空间中只有4,294,967,296（2^32） 个地址。 IPv4地址可被写作任何表示一个32位整数值的形式，但为了方便人类阅读和分析，它通常被写作点分十进制的形式，即四个字节被分开用十进制写出，中间用点分隔。 所以，通常IPv4地址的地址格式为nnn.nnn.nnn.nnn，如： 1 192.0.2.235 因为在点分十进制的表达形势下，共有4个字节的IP地址被分位四段，每一段就有一个字节，而一个字节有8位，那么，8位能表示的数字范围是 0 - 255。 所以，一个IPv4的地址，格式为nnn.nnn.nnn.nnn，其中 0<=nnn<=255，而每个 n 都是十进制数。可省略前导零。 IPv4报文格式 我们知道，在TCP/IP 五层协议模型中，一次网络请求要先后经过应用层->传输层->网络层->数据链路层->物理层。 而在请求过程中，一个请求数据也会从应用层到物理层经过层层包装，每一层把上一层的数据报文包装后加上一层头部信息之后再传给下一层。 所以，IPv4作为网络层协议，在其报文结构中，同样包含了IP首部和数据部分。 其中，IPv4的首部长度是可变的，范围在20-60字节之间。 首部 IPv4报文的首部包含14个字段，其中13个是必须的，1个是可选的。 上图是一张IPv4报文的首部格式，可以看到，IPv4首部中包含的内容还是很多的，比如版本号，首部长度，标识符，分片偏移，存活时间，协议等。 由于这部分不是本文的重点，这里就不对报文头展开详细介绍了，读者可以参照上图自行学习下。 数据 报文中，除了首部以外，还有一个最重要的部分那就是数据部分，数据字段不是首部的一部分，因此并不被包含在首部检验和中。 前面说过，网络层会把传输层的报文封装成数据，并添加上首部之后传递给链路层。 所以，IPv4的报文中数据部分就是传输层的协议报文内容，如TCP、UDP等。 为什么IPv4会枯竭？ IP地址的全球性管理机构为互联网号码分配局（IANA），其下有五个局域网际网络注册管理机构（RIR） 在理论上，IPv4最多可以提供2^32 （约42.9亿）个IP地址。不过，一些地址是为特殊用途所保留的，如约1800万个专用网络和约2.7亿个多播地址，同样减少了可在互联网上路由的地址数量。 随着地址不断被分配给终端用户，IPv4地址枯竭问题也在随之产生。 中国是世界上互联网用户数量最多的国家，但人均只有0.45个IPv4地址。在IPv4的环境下，我国用户上网地址需要动态分配，人与地址没有固定的对应关系，用户溯源难，带来互联网安全和监管隐患。 所以，为了解决这个问题，IPv6诞生了。 什么是IPv6？ IPv6是Internet Protocol version 6的缩写，中文翻译为互联网通信协议（TCP/IP协议）第6版，通常简称为网际协议版6。IPv6具有比IPv4大得多的编码地址空间，用它来取代IPv4主要是为了解决IPv4地址枯竭问题，同时它也在其他方面对于IPv4有许多改进。 ...

典型回答 三次握手 你（客户端）给一个朋友（服务器）打电话，告诉他你想开始对话。这就像是发送一个SYN（同步序列编号）信号，表示你想开始建立连接。（client向server发送syn，seq=x，此时client验证client发送能力正常。client置为SYN_SENT状态） 你的朋友接到电话，明白你想开始对话。他回应说“好的，我准备好了”，同时也告诉你他也想说些话。这就相当于服务器发送SYN-ACK（同步和确认）信号，既确认收到了你的请求，也表明它准备好了并想建立连接。（server收到syn，此时server验证client发送能力正常，server接收能力正常。server向client发送ack = x + 1,seq = y，此时server验证server发送能力正常。server置为SYN_RCVD状态） 最后，你回复你的朋友说你收到了他的确认，现在可以开始对话了。这就是发送ACK（确认）信号，确认你已经准备好进行通信。（client收到ack，此时client验证client接收能力正常，server接收发送能力正常。client向server发送ack = y + 1， seq = x + 1，server接收到后验证client接收能力正常。client置为ESTABLISHED状态） 四次挥手 你（客户端）和朋友（服务器）通话结束后，告诉他你想挂电话了。这就像是发送一个FIN（结束）信号，表示你想结束这次连接。（client向server发送fin。client置为FIN_WAIT_1） 朋友听到你想挂电话了，他回应说“知道了，但我还有点事情要处理”，即使他知道对话即将结束。这就相当于服务器发送ACK（确认）信号，确认收到了你想结束连接的请求，但可能还需要一些时间来处理剩余的数据。（server向client发送ack。server置为CLOSE_WAIT，client置为FIN_WAIT_2） 一段时间后，你的朋友处理完了他的事情，这时他打电话告诉你他也准备好挂电话了。这是服务器端发送第二个FIN信号，表明他现在也准备好结束这次连接。（等server传输数据完毕后，向client发送fin。server置为LAST_ACK） 最后，你回复说你收到了他的消息，并同意现在可以挂电话了。这就是发送最后一个ACK信号，确认收到服务器端的结束请求。（client向server发送ack。client置为TIME_WAIT。之后等待2MSL，client关闭。server接收到后置为CLOSED） 其中等待2倍的最大报文段生存时间（2MSL，Maximum Segment Lifetime）是为了确保在网络中的所有剩余数据报文段都被丢弃，以防止旧的数据报文段在之后的连接中引发混淆或冲突。 知识扩展 为啥三次握手 TCP三次握手验证了client和server的收包和发包能力。 第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。 第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。 所以，只有三次握手才能确认双方的接收与发送能力是否正常。 如果是两次握手，服务端无法确定客户端是否已经接收到了自己发送的初始序列号，如果第二次握手报文丢失，那么客户端就无法知道服务端的初始序列号，那 TCP 的可靠性就无从谈起。 客户端由于某种原因发送了两个不同序号的 SYN 包，我们知道网络环境是复杂的，旧的数据包有可能先到达服务器。如果是两次握手，服务器收到旧的 SYN 就会立刻建立连接，那么会造成网络异常。 如果是三次握手，服务器需要回复 SYN+ACK 包，客户端会对比应答的序号，如果发现是旧的报文，就会给服务器发 RST 报文，直到正常的 SYN 到达服务器后才正常建立连接。 所以三次握手才有足够的上下文信息来判断当前连接是否是历史连接。 为啥四次挥手 其实在 TCP 握手的时候，接收端发送 SYN+ACK 的包是将一个 ACK 和一个 SYN 合并到一个包中，所以减少了一次包的发送，三次完成握手。 对于四次挥手，因为** TCP 是全双工通信**，在主动关闭方发送 FIN 包后，接收端可能还要发送数据，不能立即关闭服务器端到客户端的数据通道，所以也就不能将服务器端的 FIN 包与对客户端的 ACK 包合并发送，只能先确认 ACK，然后服务器待无需发送数据时再发送 FIN 包，所以四次挥手时必须是四次数据包的交互。 ...

典型回答 TCP粘包和拆包问题是指在进行TCP通信时，因为TCP是面向流的，所以发送方在传输数据时可能会将多个小的数据包粘合在一起发送，而接收方则可能将这些数据包拆分成多个小的数据包进行接收，从而导致数据接收出现错误或者数据粘连的问题。 TCP粘包和拆包问题主要出现在以下两种情况下： 发送方连续发送多个小数据包：由于TCP是基于流的协议，发送方在传输数据时可能会将多个小数据包组合成一个大数据包进行发送，从而导致接收方在接收数据时无法区分不同数据包之间的界限。 接收方缓存区大小限制：接收方在接收数据时，如果接收缓存区的大小有限，可能会将一个大的数据包拆分成多个小数据包进行接收，从而导致粘包和拆包问题的出现。 解决方案 对于粘包和拆包问题，一般都是对包的格式进行约束，常见的解决方案有四种： 将业务层协议包的长度固定下来，每个包都固定长度，比如512个字节大小，如果客户端发送的数据长度不足512个字节，则通过补充空格的方式补全到指定长度； 在每个包的末尾使用固定的分隔符，如换行符/n，如果一个包被拆分了，则等待下一个包发送过来之后找到其中的\n，然后对其拆分后的头部部分与前一个包的剩余部分进行合并即可； 仿照TCP/IP协议栈，将消息分为header和body，在head中保存有当前整个消息的长度，只有在读取到足够长度的消息之后才算是读到了一个完整的消息； 通过自定义协议进行粘包和拆包的处理。