TCP三次握手四次挥手、粘包问题

一、TCP三次握手，挥手四次？

    ACK：确认序号有效。 SYN：发起一个新连接。 FIN：释放一个连接。

    三次握手，即建立TCP连接，需要客户端和服务端总共发送至少三个包确认连接的建立。

    四次挥手：即终止TCP连接，需要客户端和服务端总共发送4个包确认连接的断开

建立连接

    第一次握手

        Client将标志位SYN置1，随机产生一个值seq=J,并将数据包发给Server
        Client进入SYN_SENT状态，等待Server确认

    第二次握手

        Server收到数据包后标志位SYN=1知道Client请求建立连接，Server将标志位SYN和ACK都置1，随机产生一个值,并将数据包发给Client确认连接请求，Server进入SYN_RCVD状态

    第三次握手

       Client收到确认后若ACK为1，则将该数据包发送给Server，Server检查ACK为1则连接建立成功，Client与Server进入ESTABLISHED状态完成三次握手，可以传输数据

因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。

关闭连接

    第一次挥手：

        Clien发送一个FIN，用来关闭Client到Server的数据传送，Client进入FIN_WAIT_1状态。

    第二次挥手：

        Server收到FIN后，发送一个ACK给Client,Server进入CLOSE_WAIT状态。

    第三次挥手：

         Server发送一个FIN，用来关闭Server到Client的数据传送，Server进入LAST_ACK状态。

    第四次挥手：

       Client收到FIN后，Client进入TIME_WAIT状态，发送ACK给Server，Server进入CLOSED状态，完成四次握手。

当收到对方的FIN报文时，仅表示对方不再发送数据但还能接收收据，我们也未必把全部数据都发给了对方，所以我们可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方表示同意关闭连接。因此我们的ACK和FIN一般会分开发送。

二、 TCP 有哪些状态？

tcp连接全过程各种状态详解

11种 状态

1. LISTEN：侦听来自远方的TCP端口的连接请求
2. SYN-SENT：再发送连接请求后等待匹配的连接请求（客户端）
3. SYN-RECEIVED：再收到和发送一个连接请求后等待对方对连接请求的确认（服务器）
4. ESTABLISHED：代表一个打开的连接
5. FIN-WAIT-1：等待远程TCP连接中断请求，或先前的连接中断请求的确认
6. FIN-WAIT-2：从远程TCP等待连接中断请求
7. CLOSE-WAIT：等待从本地用户发来的连接中断请求
8. CLOSING：等待远程TCP对连接中断的确认
9. LAST-ACK：等待原来的发向远程TCP的连接中断请求的确认
10. TIME-WAIT：等待足够的时间以确保远程TCP接收到连接中断请求的确认
11. CLOSED：没有任何连接状态

客户端的状态可以用如下的流程来表示： 
CLOSED -> SYN_SENT -> ESTABLISHED -> FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT -> CLOSED

服务器的状态可以用如下的流程来表示： 
CLOSED -> LISTEN -> SYN收到 -> ESTABLISHED -> CLOSE_WAIT -> LAST_ACK -> CLOSED

三、在浏览器输入一个URL，按下回车之后会经过哪些流程？

• DNS域名解析，得到IP地址

  DNS解析流程:

  ​ 1.在主机查询DNS缓存，如果没有就会给本地的DNS发送查询请求

  ​ 2.本地的DNS服务器向根域名服务器发送查询请求，根域名服务器返回该域名的一级域名服务器

  ​ 3.该本地服务器给该一级域名服务器发送查询请求，然后依次类推直到查询到该域名的IP地址

• 解析出IP地址后，根据IP地址和默认端口80和服务器建立连接

• 浏览器发出读取文件（URL中域名后边部分对应的文件）的HTTP请求，该请求报文作为TCP三次握手的第三个报文的数据发送给服务器

• 服务器对浏览器的请求作出响应，并把对应的html文本发送给浏览器

• 释放TCP连接（四次挥手断开连接）

• 浏览器解析该HTML文本并显示内容

 七层网络模型：

四、TCP如何解决粘包问题？

TCP/IP四层网络模型每层各司其职，消息在进入每一层时都会多加一个报头，每多一个报头可以理解为数据报多戴一顶帽子。这个报头上面记录着消息从哪来，到哪去，以及消息多长等信息。比如，mac头部记录的是硬件的唯一地址，IP头记录的是从哪来和到哪去，传输层头记录到是到达目的主机后具体去哪个进程。 

 

• MTU: Maximum Transmit Unit，最大传输单元。 由网络接口层（数据链路层）提供给网络层最大一次传输数据的大小；一般 MTU=1500 Byte。
  假设IP层有 <= 1500 byte 需要发送，只需要一个 IP 包就可以完成发送任务；假设 IP 层有> 1500 byte 数据需要发送，需要分片才能完成发送，分片后的 IP Header ID 相同。

• MSS：Maximum Segment Size 。TCP 提交给 IP 层最大分段大小，不包含 TCP Header 和  TCP Option，只包含 TCP Payload ，MSS 是 TCP 用来限制应用层最大的发送字节数。
  假设 MTU= 1500 byte，那么 MSS = 1500- 20(IP Header) -20 (TCP Header) = 1460 byte，如果应用层有 2000 byte 发送，那么需要两个切片才可以完成发送，第一个 TCP 切片 = 1460，第二个 TCP 切片 = 540。

 TCP，Transmission Control Protocol。传输控制协议，是一种面向连接的、可靠的、基于字节流的传输层通信协议。

其中跟粘包关系最大的就是基于字节流这个特点。

字节流可以理解为一个双向的通道里流淌的数据，这个数据其实就是我们常说的二进制数据，简单来说就是一大堆 01 串。这些 01 串之间没有任何边界。

应用层传到 TCP 协议的数据，不是以消息报为单位向目的主机发送，而是以字节流的方式发送到下游，这些数据可能被切割和组装成各种数据包，接收端收到这些数据包后没有正确还原原来的消息，因此出现粘包现象。

解决粘包的办法：

        1、加入特殊标志

        2、加入消息长度信息

跟 TCP 同为传输层的另一个协议，UDP，User Datagram Protocol。用户数据包协议，是面向无连接，不可靠的，基于数据报的传输层通信协议。 

基于数据报是指无论应用层交给 UDP 多长的报文，UDP 都照样发送，即一次发送一个报文。至于如果数据包太长，需要分片，那也是IP层的事情，大不了效率低一些。UDP 对应用层交下来的报文，既不合并，也不拆分，而是保留这些报文的边界。而接收方在接收数据报的时候，也不会像面对 TCP 无穷无尽的二进制流那样不清楚啥时候能结束。正因为基于数据报和基于字节流的差异，TCP 发送端发 10 次字节流数据，而这时候接收端可以分 100 次去取数据，每次取数据的长度可以根据处理能力作调整；但 UDP 发送端发了 10 次数据报，那接收端就要在 10 次收完，且发了多少，就取多少，确保每次都是一个完整的数据报。 

UDP 是基于数据报的传输协议，不会有粘包问题。

 

 

在报头中有16bit用于指示 UDP 数据报文的长度，假设这个长度是 n ，以此作为数据边界。因此在接收端的应用层能清晰地将不同的数据报文区分开，从报头开始取 n 位，就是一个完整的数据报，从而避免粘包和拆包的问题。

当然，就算没有这个位（16位 UDP 长度），因为 IP 的头部已经包含了数据的总长度信息，此时如果 IP 包（网络层）里放的数据使用的协议是 UDP（传输层），那么这个总长度其实就包含了 UDP 的头部和 UDP 的数据。

 IP 层有粘包问题吗？

• 如果消息过长，IP层会按 MTU 长度把消息分成 N 个切片，每个切片带有自身在包里的位置（offset）和同样的IP头信息。

• 各个切片在网络中进行传输。每个数据包切片可以在不同的路由中流转，然后在最后的终点汇合后再组装。

• 在接收端收到第一个切片包时会申请一块新内存，创建IP包的数据结构，等待其他切片分包数据到位。

• 等消息全部到位后就把整个消息包给到上层（传输层）进行处理。

 IP 层也切片，但是因为不关心消息里有啥，因此有不会有粘包问题。

粘包问题参考资料：硬核图解TCP粘包