1 UDP
1.1 ⾯向报⽂
- UDP 是⼀个⾯向报⽂（报⽂可以理解为⼀段段的数据）的协议。意思就是UDP 只是报⽂的搬运⼯，不会对报⽂进⾏任何拆分和拼接操作
具体来说
- 在发送端，应⽤层将数据传递给传输层的 UDP 协议， UDP 只会给数据增加⼀个 UDP头标识下是 UDP 协议，然后就传递给⽹络层了
- 在接收端，⽹络层将数据传递给传输层， UDP 只去除 IP 报⽂头就传递给应⽤层，不会任何拼接操作
1.2 不可靠性
- UDP 是⽆连接的，也就是说通信不需要建⽴和断开连接。
- UDP 也是不可靠的。协议收到什么数据就传递什么数据，并且也不会备份数据，对⽅能不能收到是不关⼼的
- UDP 没有拥塞控制，⼀直会以恒定的速度发送数据。即使⽹络条件不好，也不会对发送速率进⾏调整。这样实现的弊端就是在⽹络条件不好的情况下可能会导致丢包，但是优点也很明显，在某些实时性要求⾼的场景（⽐如电话会议）就需要使⽤ UDP ⽽不是 TCP
1.3 ⾼效
- 因为 UDP 没有 TCP 那么复杂，需要保证数据不丢失且有序到达。所以 UDP 的头部开销⼩，只有⼋字节，相⽐ TCP 的⾄少⼆⼗字节要少得多，在传输数据报⽂时是很⾼效的
头部包含了以下⼏个数据
- 两个⼗六位的端⼝号，分别为源端⼝（可选字段）和⽬标端⼝ 整个数据报⽂的⻓度
- 整个数据报⽂的检验和（ IPv4 可选 字段），该字段⽤于发现头部信息和数据中的错误
1.4 传输⽅式
- UDP 不⽌⽀持⼀对⼀的传输⽅式，同样⽀持⼀对多，多对多，多对⼀的⽅式，也就是说 UDP 提供了单播，多播，⼴播的功能
2 TCP
2.1 头部
- TCP 头部⽐ UDP 头部复杂的多
- 对于 TCP 头部来说，以下⼏个字段是很重要的
- Sequence number ，这个序号保证了 TCP 传输的报⽂都是有序的，对端可以通过序号顺序的拼接报⽂
- Acknowledgement Number ，这个序号表示数据接收端期望接收的下⼀个字节的编号是多少，同时也表示上⼀个序号的数据已经收到
- Window Size ，窗⼝⼤⼩，表示还能接收多少字节的数据，⽤于流量控制
标识符
- URG=1 ：该字段为⼀表示本数据报的数据部分包含紧急信息，是⼀个⾼优先级数据报⽂，此时紧急指针有效。紧急数据⼀定位于当前数据包数据部分的最前⾯，紧急指针标明了紧急数据的尾部。
- ACK=1 ：该字段为⼀表示确认号字段有效。此外， TCP 还规定在连接建⽴后传送的所有报⽂段都必须把 ACK 置为⼀ PSH=1 ：该字段为⼀表示接收端应该⽴即将数据 push 给应⽤层，⽽不是等到缓冲区满后再提交。
- RST=1 ：该字段为⼀表示当前 TCP 连接出现严重问题，可能需要重新建⽴ TCP 连接，也可以⽤于拒绝⾮法的报⽂段和拒绝连接请求。
- SYN=1 ：当 SYN=1 ， ACK=0 时，表示当前报⽂段是⼀个连接请求报⽂。当 SYN=1 ，ACK=1 时，表示当前报⽂段是⼀个同意建⽴连接的应答报⽂。
- FIN=1 ：该字段为⼀表示此报⽂段是⼀个释放连接的请求报⽂
2.2 状态机
- HTTP 是⽆连接的，所以作为下层的 TCP 协议也是⽆连接的，虽然看似
- TCP 将两端连接了起来，但是其实只是两端共同维护了⼀个状态
- TCP 的状态机是很复杂的，并且与建⽴断开连接时的握⼿息息相关，接下来就来详细描述下两种握⼿。
- 在这之前需要了解⼀个重要的性能指标 RTT。该指标表示发送端发送数据到接收到对端数
据所需的往返时间
建⽴连接三次握⼿
- 在 TCP 协议中，主动发起请求的⼀端为客户端，被动连接的⼀端称为服务端。不管是客户端还是服务端， TCP 连接建⽴完后都能发送和接收数据，所以 TCP 也是⼀个全双⼯的协议。
- 起初，两端都为 CLOSED 状态。在通信开始前，双⽅都会创建 TCB 。 服务器创建完TCB 后遍进⼊ LISTEN 状态，此时开始等待客户端发送数据
第⼀次握⼿
客户端向服务端发送连接请求报⽂段。该报⽂段中包含⾃身的数据通讯初始序
号。请求发送后，客户端便进⼊ SYN-SENT 状态，x 表示客户端的数据通信初
始序号。
第⼆次握⼿
服务端收到连接请求报⽂段后，如果同意连接，则会发送⼀个应答，该应答中也会包含⾃身的数据通讯初始序号，发送完成后便进⼊ SYN-RECEIVED 状态。
第三次握⼿
当客户端收到连接同意的应答后，还要向服务端发送⼀个确认报⽂。客户端发完这个报⽂段后便进⼊ ESTABLISHED 状态，服务端收到这个应答后也进⼊ESTABLISHED 状态，此时连接建⽴成功。
- PS：第三次握⼿可以包含数据，通过 TCP 快速打开（ TFO ）技术。其实只要涉及到握⼿的协议，都可以使⽤类似 TFO 的⽅式，客户端和服务端存储相同 cookie ，下次握⼿时发出 cookie 达到减少 RTT 的⽬的
你是否有疑惑明明两次握⼿就可以建⽴起连接，为什么还需要第三次应答？
- 因为这是为了防⽌失效的连接请求报⽂段被服务端接收，从⽽产⽣错误
- 可以想象如下场景。客户端发送了⼀个连接请求 A，但是因为⽹络原因造成了超时，这时 TCP 会启动超时重传的机制再次发送⼀个连接请求 B。此时请求顺利到达服务端，服务端应答完就建⽴了请求。如果连接请求 A 在两端关闭后终于抵达了服务端，那么这时服务端会认为客户端⼜需要建⽴ TCP 连接，从⽽应答了该请求并进⼊ ESTABLISHED 状态。此时客户端其实是 CLOSED 状态，那么就会导致服务端⼀直等待，造成资源的浪费
- PS：在建⽴连接中，任意⼀端掉线，TCP 都会重发 SYN 包，⼀般会重试五次，在建⽴连接中可能会遇到 SYN FLOOD 攻击。遇到这种情况你可以选择调低重试次数或者⼲脆在不能处理的情况下拒绝请求
断开链接四次握⼿
TCP 是全双⼯的，在断开连接时两端都需要发送 FIN 和 ACK 。
第⼀次握⼿
- 若客户端 A 认为数据发送完成，则它需要向服务端 B 发送连接释放请求。
第⼆次握⼿
- B 收到连接释放请求后，会告诉应⽤层要释放 TCP 链接。然后会发送 ACK包，并进⼊ CLOSE_WAIT 状态，表示 A 到 B 的连接已经释放，不接收 A 发的数据了。但是因为 TCP 连接时双向的，所以 B 仍旧可以发送数据给 A。
第三次握⼿
- B 如果此时还有没发完的数据会继续发送，完毕后会向 A 发送连接释放请求，然后 B 便进⼊ LAST-ACK 状态。
- PS：通过延迟确认的技术（通常有时间限制，否则对⽅会误认为需要重传），可以将第⼆次和第三次握⼿合并，延迟 ACK 包的发送。
第四次握⼿
- A 收到释放请求后，向 B 发送确认应答，此时 A 进⼊ TIME-WAIT 状态。该状态会持续2MSL（最⼤段⽣存期，指报⽂段在⽹络中⽣存的时间，超时会被抛弃） 时间，若该时间段内没有 B 的重发请求的话，就进⼊ CLOSED 状态。当 B 收到确认应答后，也便进⼊CLOSED 状态。
为什么 A 要进⼊ TIME-WAIT 状态，等待 2MSL 时间后才进⼊ CLOSED 状态？
- 为了保证 B 能收到 A 的确认应答。若 A 发完确认应答后直接进⼊ CLOSED 状态，如果确认应答因为⽹络问题⼀直没有到达，那么会造成 B 不能正常关闭