TCP/UDP协议

TCP/UDP协议位于传输层：负责应用程序之间的数据传输（通过端口的描述来描述哪两个进程在进行通信）。

一、UDP协议
1、协议格式
UDP协议的报头只有8个字节

16位源端端口/16位对端端口：描述端与端之间的通信。

16位UDP长度：限制了UDP总报文的长度（包含报头）不能超过64K。

16位UDP校验和：使用二进制反码进行求和，校验接收的数据是否和发送的数据一致。

二进制反码求和算法：对报文从头开始的每个字节进行取反相加，高于16位则截断高位，与低16位继续相加，最后得到校验和。

2、特性
无连接：不需要建立连接，只要知道对方的地址信息就可以直接发送数据。

不可靠：UDP在传输层中不保证数据能够安全有序的到达对端端口。

面向数据报：有最大长度限制的传输方式——取决于数据报长度。对于UDP来说，数据长度不能大于64K-8（报头长度）。

注意：因为UDP通信在报头中确定了数据报长度，因此UDP的数据发送是整条发生的。因此，recvfrom只能接收一条完整的数据，所以当数据长度大于数据报长度时，recvfrom就会报错。

二、TCP协议
1、协议格式

16位源端端口/16位对端端口：描述端与端之间的通信。

32位序号/32位确认序号：实现TCP的包序管理——TCP是有序交付的。

4位首部长度：以4字节为单位描述TCP报头长度（20字节~60字节）。

6位标志位：
URG：紧急指针是否有效
ACK：确认号是否有效
PSH：提示接收端应用程序立即从TCP缓冲区把数据读走
RST：对方要求重新建立连接，复位报文段
SYN：请求建立连接，同步报文段
FIN：通知对方，本端要关闭了，结束报文段

16位窗口大小：实现滑动窗口机制，进行流量控制。

16位UDP校验和：使用二进制反码进行求和，校验接收的数据是否和发送的数据一致。

16位紧急指针：带外数据，标识那部分数据是紧急数据。

2、特性
有连接：连接建立成功后才能进行通信。

可靠传输：TCP在传输层中可以保证数据能够安全有序的到达对端端口。

面向字节流：当应用程序传送的数据块太长，TCP就可以把它划分短一些再传送。如果应用程序一次只发送一个字节，TCP也可以等待积累有足够多的字节后再构成报文段发送出去。

3、连接/断开过程
连接过程（三次握手）

第一次握手： 客户端创建套接字，向服务端发送SYN包，并进入SYN_SEND状态，等待服务端确认。（其中，SYN=1，ACK=0，表示这是一个TCP连接请求数据报文；序号seq=x，表明传输数据时的第一个数据字节的序号是x）

第二次握手： 服务端收到请求后，必须确认客户的数据包。同时自己也发送一个SYN包，即SYN+ACK包，此时服务器进入SYN_RECV状态。其中包SYN、ACK标志位为1，发送顺序号seq=y(随机int)，接收顺序号ACK=x+1，此时服务器进入SYN接收状态。

第三次握手： 客户端收到服务端传来的包后，向服务器发送第三个包，SYN=0, ACK=1，接收顺序号ACK = y+1,发送顺序号seq=x+1。此包发送完毕，客户端和服务器进入ESTABLISHED建立成功状态，完成三次握手。

断开连接（四次挥手）

第一次挥手： 主动关闭方发送第一个包，其中FIN标志位为1，发送顺序号seq为u，进入FIN-WAIT-1状态。

第二次挥手： 被动关闭方收到FIN包后发送第二个包，其中发送顺序号seq为y，接收顺序号ACK为x+1，进入CLOSE-WAIT状态。此时主动关闭方收到回复后进入FIN-WAIT-2状态。

第三次挥手： 被动关闭方再发送第三个包，其中FIN标志位为1，发送顺序号seq为y，接收顺序号ACK为x，进行LAST-ACK状态。

第四次挥手： 主动关闭方发送第四个包，其中发送顺序号为x，接收顺序号为y，进入TIME-WAIT状态。至此，完成四次挥手。

其整体流程如下：

问题：
1、为什么要进行三次握手？
第三次握手是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

假设客户端请求建立连接，发给服务器SYN包等待服务器确认，服务器收到确认后，如果是两次握手，假设服务器给客户端在第二次握手时发送数据，数据从服务器发出，服务器认为连接已经建立，但在发送数据的过程中数据丢失，客户端认为连接没有建立，会进行重传。 假设每次发送的数据一直在丢失，客户端一直SYN，服务器就会产生多个无效连接，占用资源，这个时候服务器可能会挂掉。 这个现象就是我们听过的“SYN的洪水攻击”。

如果有第三次握手，客户端会忽略服务器之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

2、为什么要进行四次挥手？
为了资源的可以重复利用，客户端和服务端的信道必须是一起关闭（不允许发生一方端口打开，另一方端口关闭的状态），服务端在向客户端发送FIN报文后，必须确保客户端收到FIN报文（换言之，如果报文在传输过程中丢了，服务端要负责重发FIN报文），否则就会发生服务端已关闭，客服端还处于FIN-WAIT（没关闭）的状态。

3、为什么要等待2MSL？
MSL(Maximum Segment Lifetime)指的是最大报文存活时间。 RFC 793中规定MSL为2分钟，实际应用中常用的是30秒、1分钟、2分钟等。

TCP的TIME_WAIT需要等待2MSL，当TCP的一端发起主动关闭，三次挥手完成后发送第四次挥手的ACK包后就进入这个状态，等待2MSL时间主要目的是：防止最后一个ACK包对方没有收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可以继续使用。 当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。