网络协议-TCP、UDP区别及TCP三次握手、四次挥手

男娘i 2023-10-01 23:13 20阅读 0赞

#### OSI七层模型 ####

**OSI**采用了分层的结构化技术，共分七层，**物理层、数据链路层、网络层、传输层、会话层、表示层、应用层**。

#### TCP/IP模型 ####

OSI模型比较复杂且学术化，所以我们实际使用的TCP/IP模型，共分4层，**链路层、网络层、传输层、应用层**。两个模型之间的对应关系如图所示：

![3cbff83c8fa74204921f637d92e079b3.jpeg][]

无论什么模型，每一个抽象层建立在低一层提供的服务上，并且为高一层提供服务。

#### TCP/IP协议族 ####

Transmission Control Protocol/Internet Protocol的简写，中译名为传输控制协议/因特网互联协议，是 Internet 最基本的协议、Internet 国际互联网络的基础，由网络层的 IP 协议和传输层的 TCP 协议组成。协议采用了4层的层级结构。然而在很多情况下，它是利用 IP 进行通信时所必须用到的协议群的统称。

![65f5cee1e4114c1cad8a1b5d7d26f10b.jpeg][]

#### TCP/IP 网络传输中的数据 ####

每个分层中，都会对所发送的数据附加一个**首部**，在这个**首部中包含了该层必要的信息，如发送的目标地址以及协议相关信息**。通常，为协议提供的信息为包首部，所要发送的内容为数据。在下一层的角度看，从上一层收到的包全部都被认为是本层的数据。

网络中传输的数据包由两部分组成：一部分是协议所要用到的首部，另一部分是上一层传过来的数据。首部的结构由协议的具体规范详细定义。在数据包的首部，明确标明了协议应该如何读取数据。反过来说，看到首部，也就能够了解该协议必要的信息以及所要处理的数据。

![b83964342a4043de94c689a0235ff465.jpeg][]

① 应用程序处理  
首先应用程序会进行编码处理，这些编码相当于 OSI 的表示层功能；  
编码转化后，邮件不一定马上被发送出去，这种何时建立通信连接何时发送数据的管理功能，相当于 OSI 的会话层功能。

② TCP 模块的处理  
TCP 根据应用的指示，负责建立连接、发送数据以及断开连接。TCP 提供将应用层发来的数据顺利发送至对端的可靠传输。为了实现这一功能，需要在应用层数据的前端附加一个 TCP 首部。

③ IP 模块的处理  
IP 将 TCP 传过来的 TCP 首部和 TCP 数据合起来当做自己的数据，并在 TCP 首部的前端加上自己的 IP 首部。IP 包生成后，参考路由控制表决定接受此 IP 包的路由或主机。

④ 网络接口（以太网驱动）的处理  
从 IP 传过来的 IP 包对于以太网来说就是数据。给这些数据附加上以太网首部并进行发送处理，生成的以太网数据包将通过物理层传输给接收端。

⑤ 网络接口（以太网驱动）的处理  
主机收到以太网包后，首先从以太网包首部找到 MAC 地址判断是否为发送给自己的包，若不是则丢弃数据。  
如果是发送给自己的包，则从以太网包首部中的类型确定数据类型，再传给相应的模块，如 IP、ARP 等。这里的例子则是 IP 。

⑥ IP 模块的处理  
IP 模块接收到数据后也做类似的处理。从包首部中判断此 IP 地址是否与自己的 IP 地址匹配，如果匹配则根据首部的协议类型将数据发送给对应的模块，如 TCP、UDP。这里的例子则是 TCP。  
另外吗，对于有路由器的情况，接收端地址往往不是自己的地址，此时，需要借助路由控制表，在调查应该送往的主机或路由器之后再进行转发数据。

⑦ TCP 模块的处理  
在 TCP 模块中，首先会计算一下校验和，判断数据是否被破坏。然后检查是否在按照序号接收数据。最后检查端口号，确定具体的应用程序。数据被完整地接收以后，会传给由端口号识别的应用程序。

⑧ 应用程序的处理  
接收端应用程序会直接接收发送端发送的数据。通过解析数据，展示相应的内容。

#### TCP 和 UDP ####

网际协议IP是TCP/IP中非常重要的协议。负责对数据加上IP地址（有发送它的主机的地址（源地址）和接收它的主机的地址（目的地址））和其他的数据以确定传输的目标。

而 TCP 和 UDP 都是传输层的协议，传输层主要为两台主机上的应用程序提供端到端的通信。

但是 TCP 和 UDP 最不同的地方是，TCP 提供了一种**可靠的数据传输服务**，TCP 是面向连接的，也就是说，利用 TCP 通信的两台主机首先要经历一个建立连接的过程，等到连接建立后才开始传输数据，而且传输过程中采用**“带重传的肯定确认”**技术来实现传输的可靠性。TCP 还采用一种称为“滑动窗口”的方式进行流量控制，发送完成后还会关闭连接。所以 TCP 要比 UDP 可靠的多。

UDP（User Datagram Protocol的简称， 中文名是用户数据报协议）是把数据直接发出去，而不管对方是不是在接收，也不管对方是否能接收的了，也不需要接收方确认，属于不可靠的传输，可能会出现丢包现象，实际应用中要求程序员编程验证。

**注意：**  
我们一些常见的网络应用基本上都是基于 TCP 和 UDP 的，这两个协议又会使用网络层的 IP 协议。但是我们完全可以绕过传输层的 TCP 和 UDP，直接使用 IP，比如 Linux 中 LVS，甚至直接访问链路层，比如 tcpdump 程序就是直接和链路层进行通信的。

![89d29f6fcb354a61a85584d54ee6f398.jpeg][]

上图中，其他一些协议的名称解释：  
**ICMP** 控制报文协议  
**IGMP** internet组管理协议  
**ARP** 地址解析协议  
**RARP** 反向地址转化协议

#### 详解 TCP 协议特点 ####

TCP 是传输层协议，对应 OSI 网络模型的第四层传输层，特点如下。

*  TCP 协议是基于链接的，也就是传输数据前需要先建立好链接，然后再进行传输。
 *  TCP 链接一旦建立，就可以在链接上进行双向的通信。
 *  TCP 的传输是基于字节流而不是报文，将数据按字节大小进行编号，接收端通过 ACK 来确认收到的数据编号，通过这种机制，TCP 协议能够保证接收数据的有序性和完整性，因此 TCP 能够提供可靠性传输。
 *  TCP 还能提供流量控制能力，通过滑动窗口来控制数据的发送速率。滑动窗口的本质是动态缓冲区，接收端根据自己的处理能力，在 TCP 的 Header 中动态调整窗口大小，通过 ACK 应答包通知给发送端，发送端根据窗口大小调整发送的的速度。
 *  仅仅有了流量控制能力还不够，TCP 协议还考虑到了网络问题可能会导致大量重传，进而导致网络情况进一步恶化，因此 TCP 协议还提供拥塞控制。TCP 处理拥塞控制主要用到了慢启动、拥塞避免、拥塞发生、快速恢复四个算法。

#### 序列号，确认号 ####

*  序列号seq（Sequence Numbers）：用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
 *  确认序号ACK（Acknowledge Number）：在接收端，用来通知发送端数据成功接收;其数值等于发送方的发送序号+1(即接收方期望接收的下一个序列号)；
 *  标志位：  
    （A）SYN：创建一个连接  
    （B）ACK：确认序号有效  
    （C）FIN：终结一个连接  
    （D）RST：重置连接。  
    （E）PSH：接收方应该尽快将这个报文交给应用层。  
    （F）URG：紧急指针（urgent pointer）有效。

#### TCP三次握手 ####

TCP 是基于链接的，所以在传输数据前需要先建立链接，TCP 在传输上是双工传输，不区分 Client 端与 Server 端，为了便于理解，我们把主动发起建连请求的一端称作 Client 端，把被动建立链接的一端称作 Server 端。

如下图，建连的时序是从上到下，左右两边分别代表 Client 端与 Server 端当时的链接状态。

![189bd6e0837948a2a4471a1133e87c6f.jpeg][]

TCP 提供面向有连接的通信传输。面向有连接是指在数据通信开始之前先做好两端之间的准备工作。

所谓三次握手是指建立一个 TCP 连接时需要客户端和服务器端总共发送三个包以确认连接的建立。在 socket 编程中，这一过程由客户端执行 connect 来触发。

**第一次握手**：客户端将标志位 SYN 置为1，随机产生一个值 seq=J，并将该数据包发送给服务器端，客户端进入 SYN\_SENT 状态，等待服务器端确认。

**第二次握手**：服务器端收到数据包后由标志位 SYN=1 知道客户端请求建立连接，服务器端将标志位 SYN 和 ACK 都置为1，ack=J+1，随机产生一个值 seq=K，并将该数据包发送给客户端以确认连接请求，服务器端进入 SYN\_RCVD 状态。

**第三次握手**：客户端收到确认后，检查 ack 是否为J+1，ACK 是否为1，如果正确则将标志位 ACK 置为1，ack=K+1，并将该数据包发送给服务器端，服务器端检查 ack 是否为K+1，ACK 是否为1，如果正确则连接建立成功，客户端和服务器端进入 ESTABLISHED 状态，完成三次握手，随后客户端与服务器端之间可以开始传输数据了。

为什么 TCP 握手需要三次?

TCP 是可靠的传输控制协议，而三次握手是保证数据可靠传输又能提高传输效率的最小次数。

**原因：**  
为了实现可靠数据传输， TCP 协议的通信双方，都必须维护一个序列号， 以标识发送出去的数据包中，哪些是已经被对方收到的。

例如：发送方在发送数据包（假设大小为 10 byte）时， 同时送上一个序号( 假设为 500)，那么接收方收到这个数据包以后， 就可以回复一个确认号（510 = 500 + 10） 告诉发送方 “我已经收到了你的数据包， 你可以发送下一个数据包， 序号从 511 开始” 。

三次握手的过程即是通信双方**相互告知**序列号起始值，并**确认对方**已经收到了序列号起始值的必经步骤。

如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。

至于为什么不是四次，很明显，三次握手后，通信的双方都已经知道了对方序列号起始值，也确认了对方知道自己序列号起始值，第四次握手已经毫无必要了。

TCP 的三次握手的漏洞-SYN洪泛攻击

TCP 三次握手中是有一个缺陷的，就是如果我们利用三次握手的缺陷进行攻击。这个攻击就是**SYN 洪泛攻击**。三次握手中有一个第二次握手，服务端向客户端应答请求，应答请求是需要客户端 IP 的，攻击者就伪造这个 IP，往服务器端狂发送第一次握手的内容，当然第一次握手中的客户端 IP 地址是伪造的，从而服务端忙于进行第二次握手但是第二次握手当然没有结果，所以导致服务器端被拖累，死机。

面对这种攻击，有以下的解决方案，最好的方案是**防火墙**。  
**无效连接监视释放**  
这种方法不停监视所有的连接，包括三次握手的，还有握手一次的，反正是所有的，当达到一定(与)阈值时拆除这些连接，从而释放系统资源。这种方法对于所有的连接一视同仁，不管是正常的还是攻击的，所以这种方式不推荐。  
**延缓TCB分配方法**  
一般的做完第一次握手之后，服务器就需要为该请求分配一个 TCB（连接控制资源），通常这个资源需要200多个字节。延迟 TCB 的分配，当正常连接建立起来后再分配 TCB 则可以有效地减轻服务器资源的消耗。

**使用防火墙**  
防火墙在确认了连接的有效性后，才向内部的服务器（Listener）发起SYN请求

#### 详解四次挥手断连 ####

TCP 的断连，如下图所示。

![c05c3c84eebb4c1d8cf3045513f182a8.jpeg][]

TCP 链接的关闭，通信双方都可以先发起，我们暂且把先发起的一方看作 Client，从图中看出，通信中 Client 和 Server 两端的链接都是 ESTABLISHED 状态，然后 Client 先主动发起了关闭链接请求，Client 向 Server 发送了一个 FIN 包，表示 Client 端已经没有数据要发送了，然后 Client 进入了 FIN\_WAIT\_1 状态。

Server 端收到 FIN 后，返回 ACK，然后进入 CLOSE\_WAIT 状态。此时 Server 属于半关闭状态，因为此时 Client 向 Server 方向已经不会发送数据了，可是 Server 向 Client 端可能还有数据要发送。

当 Server 端数据发送完毕后，Server 端会向 Client 端发送 FIN，表示 Server 端也没有数据要发送了，此时 Server 进入 LAST\_ACK 状态，就等待 Client 的应答就可以关闭链接了。

Client 端收到 Server 端的 FIN 后，回复 ACK，然后进入 TIME\_WAIT 状态。TIME\_WAIT 状态下需要等待 2 倍的最大报文段生存时间，来保证链接的可靠关闭，之后才会进入 CLOSED 关闭状态。而 Server 端收到 ACK 后直接就进入 CLOSED 状态。

为什么需要等待 2 倍最大报文段生存时间之后再关闭链接，原因有两个：

1.  保证 TCP 协议的全双工连接能够可靠关闭；
2.  保证这次连接的重复数据段从网络中消失，防止端口被重用时可能产生数据混淆。

从这个交互流程可以看出，无论是建连还是断链，都是需要在两个方向上进行，只不过建连时，Server 端的 SYN 和 ACK 合并为一次发送，而断链时，两个方向上数据发送停止的时间可能不同，所以不能合并发送 FIN 和 ACK。这就是建连三次握手而断链需要四次的原因。

另外回答断链的问题时，可以提到实际应用中有可能遇到大量 Socket 处在 TIME\_WAIT 或者 CLOSE\_WAIT 状态的问题。一般开启 tcp\_tw\_reuse 和 tcp\_tw\_recycle 能够加快 TIME-WAIT 的 Sockets 回收；而大量 CLOSE\_WAIT 可能是被动关闭的一方存在代码 bug，没有正确关闭链接导致的。

*  **为什么要等待 2MSL**  
    客户端发送的第4次握手报文，服务器没有收到。这时候服务器端会再次发送一个 FIN =1 的报文，而这个时候客户端还处于 TIME\_WAIT 状态，所以可以再次发送确认消息。

如果有大量的连接，每次在连接、关闭时都要经历三次握手、四次挥手，这很显然会造成性能低下。因此，HTTP 有一种叫作 keepalive connections 的机制，它可以在传输数据后仍然保持连接，当客户端需要再次获取数据时，直接使用刚刚空闲下来的连接而无须再次握手。

*  **为什么需要三次握手，两次确认？**  
    为什么客户端还要发送一次确认呢，主要是**为了防止已失效的链接请求报文突然又传到了服务器端，造成错误**。比如：客户端发送链接请求，因为网络或者一些其它因素造成没有在一定时间到达服务器端，所以客户没有收到确认。由于客户端会重发一次链接请求，通过三次握手与服务器建立连接，但是这时上次的请求到达服务器端了，服务器会误以为客户端又发了一次新的链接请求，会向客户端发送报文同意建立连接，但是客户端已经建立连接了，就会放弃该报文，服务端没有收到响应，也就不会建立连接了。
 *  **三次握手出现错误时的应对措施？**  
    第一次握手A发送SYN传输失败，A,B都不会申请资源，连接失败。如果一段时间内发出多个SYN连接请求，那么A只会接受它最后发送的那个SYN的SYN+ACK回应，忽略其他回应全部回应，B中多申请的资源也会释放
    
    第二次握手B发送SYN+ACK传输失败，A不会申请资源，B申请了资源，但收不到A的ACK，过一段时间释放资源。如果是收到了多个A的SYN请求，B都会回复SYN+ACK，但A只会承认其中它最早发送的那个SYN的回应，并回复最后一次握手的ACK
    
    第三次握手ACK传输失败，B没有收到ACK，释放资源，对于后序的A的传输数据返回RST(重置连接)。实际上B会因为没有收到A的ACK会多次发送SYN+ACK，次数是可以设置的，如果最后还是没有收到A的ACK，则释放资源，对A的数据传输返回RST

![a6b2bc19230c4a17828c25aa00275493.jpeg][]

[3cbff83c8fa74204921f637d92e079b3.jpeg]: https://img-blog.csdnimg.cn/3cbff83c8fa74204921f637d92e079b3.jpeg
[65f5cee1e4114c1cad8a1b5d7d26f10b.jpeg]: https://img-blog.csdnimg.cn/65f5cee1e4114c1cad8a1b5d7d26f10b.jpeg
[b83964342a4043de94c689a0235ff465.jpeg]: https://img-blog.csdnimg.cn/b83964342a4043de94c689a0235ff465.jpeg
[89d29f6fcb354a61a85584d54ee6f398.jpeg]: https://img-blog.csdnimg.cn/89d29f6fcb354a61a85584d54ee6f398.jpeg
[189bd6e0837948a2a4471a1133e87c6f.jpeg]: https://img-blog.csdnimg.cn/189bd6e0837948a2a4471a1133e87c6f.jpeg
[c05c3c84eebb4c1d8cf3045513f182a8.jpeg]: https://img-blog.csdnimg.cn/c05c3c84eebb4c1d8cf3045513f182a8.jpeg
[a6b2bc19230c4a17828c25aa00275493.jpeg]: https://img-blog.csdnimg.cn/a6b2bc19230c4a17828c25aa00275493.jpeg