TCP和UDP学习笔记

1. TCP和UDP的区别

• TCP是面向连接的，提供可靠服务的、提供流量控制和拥塞控制的、面向字节流传输层协议。
• UDP是无连接的、不可靠的、面向报文的传输层协议。
  

---

2. 面向报文和面向字节流的区别：

• 应用层交给UDP多长的报文，UDP就照样发送。即一次发送一个报文。只不过交给IP层的报文如果太长，则IP层需要分片，降低效率。若太短，则报文太短，携带数据少，效率也会降低。
• 虽然应用程序与TCP的交互是一次一个数据块，但是，TCP把应用程序传过来的数据看成一连串无结构的字节流。如果应用程序传送过来的数据块太长，TCP就把它划分小一点再发送。如果应用程序传送的数据块太小，TCP就等待积累足够多的字节后构成报文段发送出去。

---

3. 面向连接和无连接的区别：

• 面向连接：通信双方在通信前，要事先建立一条通信线路，其过程有建立连接、使用连接、释放连接三个过程。
• 无连接：就是通信双方不需要建立一条通信线路，而是把每个带有目的地址的包（报文分组）送到线路上，由系统选定线路进行传输。

---

4. 使用TCP和UDP的应用层协议：

---

5. UDP重点记录

1. UDP报文结构

---

2. UDP的优点

1. 没有握手以及拥塞控制，传输数据更快
2. 没有建立连接的时延
3. 分组首部开销小

---

3. IP分片和MTU

1. MTU：一种通信协议的某一层面上所能通过最大数据包大小（以字节为单位）
2. UDP协议下，传送的数据包大于MTU时，该怎么办？
   答：数据分片有IP层处理，按照路由路径上最小的MTU进行分片，当到达目标主机以后，在IP层对分片的数据进行组装，所以，传给UDP的包还是一个完整的包。
3. 分片以后，有些包丢了怎么办？
   答：UDP有个CRC检验。如果包不完整，就会丢弃，也不会通知发送端是否接收成功。所以，UDP是不可靠协议。TCP有自己的重传机制。

---

6. TCP重点记录

1. TCP的报文结构

TCP是面向字节流的，但是TCP传送的数据却是报文段。一个TCP报文段分为首部和数据两部分。

和UDP报文结构相似的部分：

• 源端口号和目的端口号：用于多路复用和分解
• 检验和字段

TCP报文首部与UDP不同的部分：

• 序号字段和确认号字段
• 接收窗口字段：用于流量控制，表示接收方愿意接收的字节数量
• 首部长度字段
• 选项字段：指出TCP报文段中数据的最大长度MSS；使窗口扩大；时间戳。

• 紧急指针：只有紧急URG=1才有意义。

• 标志字段：包括以下

  1. 确认ACK：当ACK=1时，确认号字段才有效。当ACK=0时，确认好无效。当连接建立前ACK=0，建立之后ACK就一直是1了。
  2. 紧急URG。当此处为1时，标明紧急指针字段有效。它告诉系统此报文段有紧急数据，需要尽快传送。系统会把紧急数据插入到TCP缓存的前面。它和紧急指针配合使用。
  3. 推送PSH。当PSH=1时，系统会立刻将此报文段发送出去，而不再等待整个缓存都被填满后才发送。
  4. 复位RST。当其为1时，标明TCP出现严重错误，必须释放连接然后再重新连接。
  5. 同步SYN：在建立连接当其为1而ACK为0时，表明这是一个（同步）连接请求报文段。当对方同意后，应该在响应报文段中使用SYN=1，ACK=1.因此，SYN=1，要么表示连接请求，要么表示连接接受报文。
  6. 终止FIN：用来释放连接。当其为1时，表明此报文段的发送方的数据已经发送完毕，要求释放连接。

---

2. TCP的三次握手和四次挥手

三次握手

• 服务器建立socket，绑定端口并进入监听模式。
• 客户端向服务器发送连接请求报文，此报文的标志位SYN=1，确认字段ACK=0（确认字段无效），初始序号seq=x（客户端初始序号）。此时，客户端进入“同步—已发送 SYN_SEND”状态。
• 服务器如果同意建立连接，分配TCP缓存和变量，发送确认报文。SYN=1，ACK=1，确认号ack=x+1。设置自己的初始序号为seq=y（服务端初始序号）。服务器进入“同步—已接收 SYN_RCVD”状态。
• 客户端收到回复以后，同样要为该连接分配缓存和变量，要给服务器发送确认。SYN=0，ACK=1，确认号ack=y+1，seq=x+1。客户端进入“已建立状态 ESTABLISHED”。
• 服务器收到后也进入“已建立状态”。

为什么要进行第三次握手？

• 主要是防止已经失效的连接请求报文重新被服务器接收到。假如客户端发送一个连接请求报文，因为网络原因未能按时到达服务器。因此，服务器未能按时给客户端回复，客户端在一段时间后重新发送了连接请求报文，服务器收到，并发送确认报文，客户端收到回复，开始传送数据，传送完毕，连接终止。这时，原先未能按时到达的连接请求报文到达了服务器，服务器以为是新的连接请求，就向客户端重新发送了确认，客户端因为没有发送连接请求，因此抛弃了服务器的确认，假如没有第三次握手，服务器在发送确认报文的时候，就已经进入连接建立状态，服务器一直在等待客户端传送数据。（假如有第三次握手，服务器在一定时间内没有收到客户端的第三次握手的确认，由于没有进入连接建立状态，就会释放连接）

---

四次挥手

• 数据传输结束后，任何一方都可以申请释放连接。
• 如上图，客户机是A，服务器是B。 A想要终止连接，A向B发送连接释放报文（FIN=1，序号seq=x，等于前面已经发送过的数据的最后一个序号+1），A进入终止-等待状态1(FIN_WAIT1)。
• B收到以后，立刻发送确认报文（ACK=1，ack=x+1）。A收到确认报文以后，进入终止-等待状态2(FIN_WAIT2)。此时TCP是半关闭的，A不能再向B发送数据，B依然可以向A发送数据，A要接收。
• 如果B没有数据要发送了，B给A发送连接释放报文（FIN=1，seq=w，ACK=1，ack=u+1），B处于最后确认状态(LAST_ACK)。A收到后立刻发送确认报文（ACK=1，ack=w+1，seq=u+1），A进入时间-等待状态(TIME_WAIT)。
• B收到确认报文，就知道可以关闭连接了，进入关闭状态。A在2MSL后没有收到请求，就证明B已经正常关闭了，然后A也关闭，进入关闭状态。

为什么A要在2MSL以后才进入关闭状态？

1. 为了报文对B的连接释放报文的确认能到达B。假如A对B连接释放的确认报文丢失了，然后B没有收到确认，一段时间后，B超时重传，如果A没有等待2MSL，A直接在第一次收到B的释放连接报文后就关闭连接了，A就无法收到B重发的连接释放报文，也就无法发送确认报文，B无法收到确认报文，B就无法正常关闭。
2. 防止已经失效的连接报文段出现。A在发送ACK报文（确认报文）后，等待2MSL，就可以使本连接所产生的所有报文段都从网络中消失，不会对下一次连接产生影响。

---

3. TCP的各种状态

1. CLOSED：初始状态
2. LISTEN：表示服务端的某个SOCKET处于监听状态
3. SYN_RCVD：表示服务端接收到了SYN报文
4. SYN_SENT：表示客户端已经发送SYN报文
5. ESTABLISHED：表示连接已经建立
6. FIN_WAIT_1和FIN_WAIT_2：在客户端发送FIN报文以后，进入FIN_WAIT_1。接收到对方回复的ACK报文后，进入FIN_WAIT_2。
7. TIME_WAIT：表示收到了对方的FIN报文，并且回复ACK以后，进入的状态，只要等2MSL后即可恢复到CLOSED初始状态了。如果在FIN_WAIT_1的状态下，接收到了对方的带有FIN和ACK标志的报文，直接进入TIME_WAIT状态。
8. CLOSING：当你发送了FIN报文，没有收到对方的ACK，反而收到FIN报文，这时进入CLOSING状态。
9. CLOSE_WAIT：当对方发送FIN报文，我回复一个ACK报文，然后我进入CLOSED_WAIT状态。
10. LAST_ACK：最后确认状态。被动关闭的一方发送FIN报文以后，等待对方的ACK报文，进入的状态。当接收到ACK报文，即可进入CLOSED状态了。

---

4. 停等式ARQ和连续式ARQ（滑动窗口协议）

• 自动重传请求ARQ包括了停等式的ARQ以及连续式ARQ，连续式ARQ也叫滑动窗口协议，包括了回退N步协议（GBN）以及选择重传协议（SR）。

• 停等式协议：每发送完一个分组就停止发送，等待对方确认，在收到确认后再传送下一个分组，信道利用率低，效率低。

• 滑动窗口协议：位于此窗口内的分组可以被连续的发送出去，而不需要等待对方的确认，因此该协议可以加速数据的传输。核心：发送方和接收方都维护了一个窗口。只有在接收窗口向前滑动时(与此同时也发送了确认)，发送窗口才有可能向前滑动。收发两端的窗口按照以上规律不断地向前滑动，因此这种协议又称为滑动窗口协议。

发送窗口和接收窗口：

1. 当发送窗口和接收窗口的大小都等于 1时，就是停止等待协议。
2. 当发送窗口大于1，接收窗口等于1时，就是回退N步协议。
3. 当发送窗口和接收窗口的大小均大于1时，就是选择重发协议。

滑动窗口协议：回退N步（GBN）

• 回退N步中，发生丢包事件后，接收方把失序后的分组都丢弃了（因为没有维护接收窗口），发送方把失序后的分组都重发了。
  

滑动窗口协议：选择重传（SR）

• 快速重传因为接收方维护了一个窗口，把失序后的分组缓存了起来，所以发送方只需要在丢失的分组超时后重传该分组就ok，接收方等到窗口内的分组都到达之后就交付给上层。
  

---

5. TCP流量控制

• 利用滑动窗口实现流量控制：如果发送方的数据发送得太快，接收方可能会来不及接收，这就会造成数据的丢失。流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

---

6. TCP的拥塞控制算法

• 拥塞控制概念：防止过多的数据注入网络中，这样可以使网络中的路由器或者链路不会过载。
• 关键：cwnd：窗口长度； 慢启动阈值：sshthresh

1. 慢启动

• 初始cwnd=1；
• 每过一个RTT，cwnd翻倍，发送速率翻倍；
• 达到慢启动阈值，转到拥塞避免阶段；

2. 拥塞避免

• 每过一个RTT，cwnd仅仅+1个MSS，发送速率缓慢增长；

3.丢包事件的两种情况：超时和冗余ACK

超时：

• sshthresh = cwnd/2;
• cwnd=1;
• 进入慢启动阶段

冗余ACK：

• sshthresh = cwnd/2;
• cwnd减半，即等于阈值sshthresh；
• 进入快速恢复阶段。

4. 快速恢复

• 与快速重传配合使用
• 收到冗余ACK后进入的阶段（cwnd减半）
• 每个冗余ACK使得cwnd+1；
• 每过一个RTT，cwnd仅仅+1（即进入了拥塞避免）

5. 补充：快速重传技术

• 接收方每收到一个失序的报文段以后，就立即发出重复确认。（为的是让发送方及早知道有报文段没有到达对方，该ack确认的是按序到达的最后一个报文）
• （2） 发送方只要一连收到三个重复确认，就立即重传对方尚未收到的报文段，而不必等待该报文段设置的计时器到时。由于发送方尽早重传未被确认的报文段，因此采用快重传后可以使整个网络吞吐量提高约20%。

• 新的TCP Reno版本在快重传之后采用快恢复算法，而不是采用慢启动算法。
• 慢启动算法只是在TCP连接建立时和网络出现超时才使用。

---