3.网络编程-TCP

TCP 建立连接的过程是怎样的

TCP为什么是三次握手

TCP 断开连接的过程是怎样的

TCP挥手为什么需要四次

为什么TIME_WAIT等待的时间是2MSL

TCP详解之滑动窗口

TCP 半连接队列和全连接队列是什么

TCP粘包，拆包是怎么发生的，如何解决

TCP是如何保证可靠性的

浏览器地址栏输入网站按回车后发生了什么

TCP 建立连接的过程是怎样的

SYN	TCP报文标志位，该位为1时表示发起一个新连接。
ACK	TCP报文标志位，该位为1时，确认序号有效,确认接收到消息。 TCP规定，在连接建立后所有报文的传输都必须把ACK置1。
seq	sequence number，报文初始序列号，代表发送的第一个字节的序号。
ack	acknowledgement number，报文确认序号，代表希望收到的下一个数据的第一个字节的序号。

TCP三次握手（Three-Way Handshake）过程描述：

第一次握手 (SYN)：
- 客户端（Client）向服务器（Server）发送一个特殊的TCP报文段，该报文段的SYN标志位置1，同时包含一个随机生成的序列号seq=X（X为客户方初始序列号）。这个报文段叫做SYN报文段。
第二次握手 (SYN + ACK)：
- 服务器接收到客户端的SYN报文段后，如果同意建立连接，则会回应一个TCP报文段，这个报文段有两个标志位置1，即SYN和ACK。服务器的SYN标志位表示也是一个连接请求，ACK标志位表示确认已收到客户端的SYN。服务器同样会生成一个随机的序列号seq=Y，并确认客户端的序列号加1作为确认号(Acknowledgment Number)，即ack=X+1。
第三次握手 (ACK)：
- 客户端收到服务器的SYN+ACK报文段后，再向服务器发送一个确认报文段，该报文段的ACK标志位置1，确认号ack=Y+1，序列号seq=X+1（通常为客户端第一次握手时的序列号加1）。

只有当三次握手全部完成以后，客户端和服务器才建立起一条可靠的TCP连接，此时双方都能确认彼此已准备好进行数据传输。

形象比喻：可以把TCP三次握手比作两个人初次见面时互相握手确认的过程：

第一个人伸出右手（相当于发送SYN）；
第二个人握住第一个人的手并伸出自己的左手（相当于发送SYN+ACK）；
第一个人再握住第二个人的左手（相当于发送ACK）；
这样，双方都确认对方伸出了手，建立了信任关系，也就是完成了连接建立的过程。

TCP为什么是三次握手

TCP（Transmission Control Protocol）采用三次握手来建立连接，这是出于以下几个主要原因：

双方确认彼此的接收与发送能力：
- 第一次握手，客户端发送SYN给服务器，服务器确认收到后，客户端得知服务器可以接收数据。
- 第二次握手，服务器回应客户端SYN+ACK，客户端收到后，服务器得知客户端不仅可以发送数据还能接收数据。
- 第三次握手，客户端发送ACK给服务器，服务器收到后确认客户端也收到了自己的SYN+ACK，从而确定双方的双向通信链路均正常。
防止旧的重复连接请求被服务器误认为是新请求：
- 如果仅采用两次握手，可能存在一种情况，即客户端发出的连接请求在网络中滞留，直到某个时刻才到达服务器，若此时客户端早已放弃连接，而服务器却认为这是一个新的连接请求并予以确认，这会导致无效的连接被建立起来。通过第三次握手，即使有旧的请求到达，服务器也会等待客户端对第二次握手的确认，从而避免了这种问题。
同步序列号（Sequence Numbers）：
- 在三次握手中，双方还交换了初始序列号(ISN)，这对于后续的数据传输是非常关键的，因为TCP连接是基于序号和确认号进行可靠传输的。通过三次握手，双方可以准确地知道本次连接的起始序号，以及对方期望接收的第一个数据字节的序号。

综上所述，三次握手既能够验证通信双方的双向通信功能正常，又能确保连接的可靠性和有序性，防止了过期连接请求被误解并建立起无效连接，因此TCP设计选择了三次握手这一机制来建立连接。

TCP 断开连接的过程是怎样的

TCP断开连接的过程通常被称为“四次挥手（Four-way Handshake）”，它确保了数据传输的可靠性，防止了数据丢失和资源泄漏。以下是TCP断开连接的详细步骤：

第一次挥手 (FIN)：
- 客户端（假设为A）想要关闭连接时，它会向服务器（假设为B）发送一个FIN（Finish）标志位设置为1的报文段，表示自己没有数据要发送了。客户端进入FIN_WAIT_1状态，等待服务器的确认。
第二次挥手 (ACK)：
- 服务器收到客户端发送的FIN报文段后，会返回一个确认报文段，其ACK（Acknowledgment）标志位为1，并且其确认号（Acknowledgment Number）设置为收到的FIN报文段的序列号加1，表示已收到客户端的关闭请求。服务器进入CLOSE_WAIT状态，此时服务器到客户端方向的连接已经关闭，但服务器仍可能有数据需要发送给客户端。
第三次挥手 (FIN)：
- 当服务器不再有数据需要发送给客户端时，服务器也会向客户端发送一个FIN标志位为1的报文段，表示它也已完成数据发送。服务器进入LAST_ACK状态，等待客户端对其FIN报文段的确认。
第四次挥手 (ACK)：
- 客户端收到服务器的FIN报文段后，会发送一个ACK标志位为1的确认报文段，确认号设置为收到的服务器FIN报文段的序列号加1。客户端进入TIME_WAIT状态，等待一段特定的时间（通常称为2MSL，即Maximum Segment Lifetime的两倍）以确保服务器收到了最后的确认报文段。
- 当服务器收到客户端的确认报文段后，它会关闭连接，进入CLOSE状态。客户端在等待的2MSL时间过后如果没有接收到任何重传的报文段，则认为服务器已经关闭了连接，客户端也随之关闭连接，进入CLOSE状态。

通过这样的四次挥手过程，TCP连接得以可靠地断开，确保了双方都知道连接已经被正常关闭，不会有任何一方还停留在半开放状态，同时也确保了网络中残留的数据包不会影响新连接的建立。

TCP挥手为什么需要四次

TCP断开连接需要四次挥手的原因在于TCP连接是全双工的，即数据可以双向流动，因此在关闭连接时，每一端都必须独立地结束自己的发送方向，并且确认对方的发送方向已经结束。

具体解释如下：

第一次挥手（FIN from Client）：
- 客户端发送一个FIN（Finished）标志的报文给服务器，表示客户端已经没有数据要发送了。
第二次挥手（ACK from Server）：
- 服务器收到客户端的FIN报文后，会发送一个ACK（Acknowledgement）报文作为确认，表示它已经收到了客户端的关闭请求。此时，服务器到客户端的方向关闭了，但服务器可能还有数据需要发送给客户端，因此连接并未完全关闭。
第三次挥手（FIN from Server）：
- 当服务器将所有剩余数据发送完毕或确定不再发送数据时，它也会发送一个FIN报文给客户端，表示服务器也已经完成了数据的发送。
第四次挥手（ACK from Client）：
- 客户端收到服务器的FIN报文后，会发送最后一个ACK报文作为确认。至此，客户端确认了服务器已经停止了数据发送，并且等待一段时间（通常称为TIME_WAIT状态）确保服务器接收到了这个ACK报文，然后才会彻底关闭连接。

总结来说，由于TCP连接的全双工特性，每端都需要分别关闭自己的发送方向，并确认对方关闭了自己的发送方向，因此形成了四次挥手的过程。这样可以确保在任何时刻，每一端都知道连接的关闭状态，避免数据丢失和资源泄露。

为什么TIME_WAIT等待的时间是2MSL

TCP在断开连接时，客户端进入TIME_WAIT状态并等待2MSL（Maximum Segment Lifetime，报文段最大生存时间）的原因是为了确保连接能够可靠关闭，并且网络中残余的数据包能够被清除，防止出现异常情况。具体理由包括：

确保最后一个ACK报文段能够被接收：
- 在TCP的四次挥手过程中，客户端发送最后一个ACK确认报文后进入TIME_WAIT状态。等待2MSL是为了确保服务器能够收到这个ACK报文。如果这个ACK报文在网络中丢失，根据TCP的重传机制，服务器将在超时后重新发送FIN报文，客户端仍在TIME_WAIT状态下，因此可以重新发送ACK，从而保证了连接的正常关闭。
避免“旧的重复报文”被当作新连接的数据：
- 如果客户端在发送完最后一个ACK后立即关闭连接，网络中可能存在延迟的、未过期的报文段。等待2MSL可以确保在此期间所有旧的重复报文段都因超过了生存时间而被丢弃。这样可以避免新建立的连接接收到来自旧连接的残留报文，确保数据的正确性和连接的独立性。

因此，TIME_WAIT状态下的客户端等待2MSL的时间窗口是一个保守的做法，用来确保网络中的TCP连接能够可靠关闭，并且不会因为旧报文段的重播而引发混淆。实际的MSL值可以根据具体实现和网络环境而有所不同，但通常建议至少等待一分钟左右。

TCP详解之滑动窗口

引入窗口概念的原因：

我们都知道 TCP 是每发送一个数据，都要进行一次确认应答。当上一个数据包收到了应答了，再发送下一个。

这个模式就有点像我和你面对面聊天，你一句我一句。但这种方式的缺点是效率比较低的。

有了窗口，就可以指定窗口大小，窗口大小就是指无需等待确认应答，而可以继续发送数据的最大值。

窗口的实现实际上是操作系统开辟的一个缓存空间，发送方主机在等到确认应答返回之前，必须在缓冲区中保留已发送的数据。如果按期收到确认应答，此时数据就可以从缓存区清除。

假设窗口大小为 3 个 TCP 段，那么发送方就可以「连续发送」 3 个 TCP 段，并且中途若有 ACK 丢失，可以通过「下一个确认应答进行确认」。

滑动窗口的工作原理如下：

发送窗口：
- 发送方有一个动态调整的发送窗口，窗口大小决定了它可以连续发送但尚未收到确认的数据量。发送方只能发送窗口内的数据，而不能发送窗口之外的数据。
接收窗口：
- 接收方同样有一个接收窗口，代表了接收缓冲区中还可以接收多少数据的大小。接收方通过通告窗口大小给发送方，以此来控制发送方的发送速率。
窗口更新：
- 随着发送方发送数据并收到接收方的确认（ACK），发送窗口会向前“滑动”，允许发送新的数据段。同时，接收方在处理完缓冲区中的数据后，也会更新其通告窗口的大小，通知发送方可以发送更多的数据。
流量控制：
- 若接收方处理速度较慢或缓冲区空间不足，会减小接收窗口大小，从而降低发送方的发送速率。反之，如果接收方处理速度快且缓冲区充足，会增大接收窗口，加快数据传输速率。
拥塞控制：
- TCP滑动窗口机制也参与拥塞控制。当网络出现拥塞时，TCP通过检测网络丢包或其他拥塞迹象来减小发送窗口，以减少对网络资源的竞争。

简而言之，TCP滑动窗口是一种灵活的、动态调整的机制，它确保了数据的可靠传输，同时也对网络的拥塞状况做出反应，协调发送端和接收端的数据传输速度，达到高效、有序、无拥塞的通信目的。

TCP 半连接队列和全连接队列是什么

TCP半连接队列和全连接队列是TCP协议在服务器端为处理连接建立过程中的不同阶段而维护的队列。

TCP半连接队列（SYN Queue 或 SYN backlog）：
- 当客户端向服务器发送一个SYN（同步）分节（即TCP三次握手的第一步）时，服务器端收到这个SYN后，会为这个连接请求创建一个条目并放置在半连接队列中，此时的连接状态为SYN_RECEIVED。
- 半连接队列的大小是有限的，如果短时间内收到大量SYN请求，超过了半连接队列的容量，服务器可能会丢弃后续的SYN请求，从而导致新的连接无法建立。这种情况有时候会被恶意利用，形成SYN Flood攻击。
TCP全连接队列（Accept Queue 或 Established Queue）：
- 当客户端发送了SYN之后，服务器回应了SYN+ACK（即TCP三次握手的第二步），并且客户端也发送了ACK（第三步），这时候TCP连接就已经建立完成，进入到ESTABLISHED状态。
- 成功完成三次握手的连接会从半连接队列移动到全连接队列，等待操作系统内核将连接分配给监听该端口的应用进程，也就是等待应用进程调用accept()函数从全连接队列取出并处理新的连接请求。
- 全连接队列的大小同样是有限的，如果超过队列大小，即使连接已经建立，但由于服务器应用程序没有及时处理，新建立的连接也会被丢弃，这也可能导致客户端看到连接建立失败。

因此，对于高并发场景，合理设置和监控半连接队列和全连接队列的大小非常重要，以防止拒绝服务攻击或连接失败的问题。在Linux系统中，可以通过调整内核参数如net.ipv4.tcp_max_syn_backlog和somaxconn来控制这两个队列的大小。

TCP粘包，拆包是怎么发生的，如何解决

TCP粘包和拆包是TCP协议在数据传输过程中可能出现的现象，主要由于TCP协议本身的特性导致的。TCP协议是一个面向连接的、可靠的、基于字节流的传输层协议，它并不保证数据包之间有明显的边界，而是将数据看作无边界的字节流进行传输。

TCP粘包的发生：

发送端：TCP为了提高传输效率，会尽可能地将数据打包在一起发送，这就是所谓的Nagle算法，它会积累一小段数据后再一次性发送，这就可能导致原本的多个小数据包在发送端被合并成一个较大的数据包，形成粘包现象。
接收端：接收端在接收数据时，可能会一次性接收到来自发送端的多个数据包，由于TCP协议本身没有消息边界，所以这些数据包在接收缓冲区中没有明显分隔，接收端无法判断哪些数据属于同一个包。

TCP拆包的发生：

当TCP数据包在传输过程中由于网络状况等因素被分片，或者数据包较大以至于不能一次性装入接收端的缓冲区，接收端可能会将一个大的数据包拆分成多个数据包接收，这就形成了拆包现象。

解决方法：解决TCP粘包和拆包问题通常需要在应用层设计一套协议，通过在数据包中添加额外的信息来标记包的开始和结束，或者是数据包的长度。以下是一些常用的解决方法：

定长消息：如果每个消息固定长度，那么接收端只需要按照固定的长度来接收和解析数据即可。
消息头包含长度：在每个数据包的前面加上包头，包头中包含消息的总长度，接收端先读取包头信息，然后根据包头中的长度信息去读取相应长度的数据。
消息边界标识符：在每个消息的末尾添加特定的边界标识符，如换行符、特殊字符序列等，通过识别这些边界标识符来分割消息。
协议自定义：设计自定义的应用层协议，如协议中明确规定每个消息应该如何封装，包括消息长度、类型、内容等信息。

在实际应用中，如WebSocket、MQTT等协议都采用了类似的机制来解决TCP粘包和拆包问题。在编写网络应用程序时，开发者需根据实际需求选择合适的方式来处理这个问题。

TCP是如何保证可靠性的

TCP（Transmission Control Protocol）为了保证数据传输的可靠性，采用了多种机制和技术，这些机制相互配合，共同确保了数据能够准确无误地从发送端传输至接收端。以下是TCP确保可靠性的主要手段：

三次握手建立连接：
- 在数据传输之前，TCP通过三次握手建立连接，确保客户端和服务端都准备好数据交换，同时也能检测链路是否可用。
序列号和确认号：
- TCP为每个发送的数据段分配一个唯一的序列号，接收方可以根据序列号正确地重组数据流，并通过确认号告知发送方哪些数据已经被成功接收。
- 这种机制使得TCP能够跟踪和处理丢失的数据段，同时也防止数据包的重复传输。
确认应答（ACK）机制：
- 接收方在接收到一个数据段后，会立即发送一个带有确认号的ACK确认帧，表明它已经收到了特定序列号之前的所有数据。
- 如果发送方未在规定时间内收到ACK确认，则假定数据段已丢失，从而触发重传。
超时重传机制：
- 发送方设置重传计时器，若在一定时间间隔（称为重传超时时间RTO）内没有收到确认，会重新发送未被确认的数据段。
错误检测：
- TCP首部包含校验和字段，用于检测数据在传输过程中是否发生错误或被篡改，如果有错误则数据会被丢弃并请求重传。
数据分块和流控：
- TCP允许数据流被分割成多个数据段，每个段独立确认和重传。
- 使用滑动窗口协议进行流量控制，发送方根据接收方通告的窗口大小调整发送速率，避免接收方无法及时处理大量数据而导致数据丢失。
拥塞控制：
- TCP通过慢启动、拥塞避免算法等策略动态调整数据发送速率，以应对网络拥塞状况，防止过多的数据涌入网络，进一步减少数据丢失的可能性。

综上所述，TCP通过以上这些机制相结合，提供了可靠的数据传输服务，确保数据的顺序交付、无丢失、无重复、无错误，并能够适应网络条件的变化。

浏览器地址栏输入网站按回车后发生了什么

当您在浏览器地址栏输入一个网站的URL并按回车键后，会发生一系列复杂的交互过程，这个过程大致可以分为以下几个步骤：

URL解析：浏览器首先解析您输入的URL，确定协议（如HTTP或HTTPS）、域名（如example.com）以及可能的路径（如/path/to/resource）和查询参数。
DNS查询：浏览器查找该域名的IP地址，首先检查本地缓存（DNS缓存），如果有则直接使用。如果没有，则通过系统的DNS解析服务逐级查询，直至获得目标服务器的IP地址。
建立TCP连接：根据URL使用的协议（HTTP或HTTPS），浏览器使用TCP/IP协议栈与服务器建立TCP连接。对于HTTPS，还需完成TLS握手过程，以加密后续通信内容。
发送HTTP请求：浏览器构造HTTP请求报文，包含请求方法（如GET、POST等）、请求头（如User-Agent、Accept、Cookie等）和可能的请求体，然后通过TCP连接发送给服务器。
服务器处理请求：服务器接收到请求后，根据请求的方法和URL解析请求，处理请求并准备响应内容。
生成HTTP响应：服务器生成HTTP响应报文，包括状态码（如200 OK）、响应头（如Content-Type、Set-Cookie等）和响应体（如HTML页面内容）。
浏览器接收响应: 浏览器接收HTTP响应，并根据响应头部和状态码进行相应处理，如解析HTML文档、下载CSS样式表、JavaScript脚本和图片等资源，并可能执行JavaScript代码。
渲染页面: 浏览器根据接收到的HTML、CSS和JavaScript构建DOM树、CSSOM树，并将它们合并成渲染树，随后进行布局和绘制，最终将渲染好的页面展示在屏幕上。