2020-12-09

TCP和UDP详解

1.传输层的功能

1. 实现进程和进程之间的逻辑通信
2. 复用和分用
3. 对收到的报文进行差错检测

2.传输控制协议TCP

提供面向连接的可靠的传输服务

提供流量控制和拥塞控制

提供点对点服务

提供可靠的交付，无差错、不丢失、不重复、按序到达

提供全双工通信，包括发送缓存和接收缓存

面向字节流，把应用层交下来的数据看成无结构的字节流处理

时延大，适用于大文件

3.TCP报文段首部格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-b2iPWXHk-1607517418601)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604130883289.png)]

序号：在一个TCP连接中传送的字节流中的每一个字节都按顺序编号，这个序号表示本报文段所发送数据的第一个字节的序号。

确认号：期望收到对方下一个报文段的第一个数据字节的序号，若确认号为N，则证明到序号N-1为止的所有数据都已经正确收到。

数据偏移（首部长度）：TCP报文端的数据起始处距离TCP报文段的起始处有多远，以4B为单位。

紧急位URG：URG=1时，标明此报文段内有紧急数据，应该插队立即传送，配合紧急指针字段使用

确认位ACK:ACK=1时确认号有效，在连接建立之后所有传送的报文都必须把ACK置为1

推送位PSH：PSH=1时，接收方尽快交付给应用进程，不再等缓存填满再向上交付

复位RST：RST=1时，表明TCP连接中有严重差错，必须释放连接，然后再重新建立连接

同步位SYN：SYN=1时，表明是一个连接请求报文或者连接请求确认报文

终止位FIN：FIN=1时，表明此报文段发送方数据已经发完，要求释放连接

窗口：接收窗口，即现在允许对方发送的数据量

检验和：和UDP类似，检验首部+数据，检验时要加上伪首部，协议字段为6

紧急指针：URG=1时才有意义，指出本报文段中紧急数据的末尾字节

选项：最大报文段长度、窗口扩大、时间戳、选择确认等

4.三次握手建立连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-C36DLuWO-1607517418614)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604132335022.png)]

1. 第一次握手：

客户端发送连接请求报文，需要将报文中首部的同步控制位置为1，即SYN=1，然后随机产生一个序号

SYN=1,seq=x（随机）

2. 第二次握手：

服务器端为该TCP连接分配缓存和变量，并向客户端返回确认报文段，同步控制位SYN=1，确认控制位ACK=1,随机产生一个序号seq=y,确认号ack也就是期望收到的下一个字节序号

SYN=1,ACK=1,seq=y,ack=x+1

3. 第三次握手：

客户端为该TCP连接分配缓存和变量，并向服务器端返回确认的确认，可以携带数据

SYN=0,ACK=1,seq=x+1,ack=y+1

4. 为什么不是两次握手或者四次握手？

三次握手旨在确认发送方和接收方都无问题，如果两次握手的话，客户端发送请求建立报文，但由于网络或者其他原因，这个请求报文过了一段时间到达服务器，则服务器会产生请求接受报文，但此时的客户端可能处于不能连接或者关机状态，服务器端会一直发送此报文，浪费服务器资源。四次握手也是浪费资源的行为。

5. SYN洪泛攻击？

客户端大量发送连接请求报文但是对于服务器端的请求接收报文不回应，导致服务器端一直重复发送请求接收报文，占用服务器资源，严重的话可能导致服务器宕机。

5.四次挥手断开连接

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-WHY2XPJc-1607517418616)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604134132890.png)]

第一次挥手：

客户端发送连接释放报文段，停止发送数据，主动关闭TCP连接，释放资源

FIN=1,seq=u

第二次挥手：

服务器端会送一个确认报文段，客户到服务器这个方向的连接就释放了，处于半关闭状态

ACK=1,seq=v,ack=u+1

第三次挥手：

服务器端发完数据，就发出连接释放报文段，主动关闭TCP连接，释放资源

FIN=1,ACK=1,seq=w,ack=u+1

第四次挥手：

客户端回送一个确认报文段，再等到时间计时器结束后，连接彻底关闭

ACK=1,seq=u+1,ack=w+1

6.TCP通过什么来保证可靠传输

1. 校验：通过伪首部校验，来保证首部和数据字段无差错
2. 序号：通过序号来保证不失序
3. 确认：保证接收方一定收到
4. 重传：没有收到接收方的接收确认，则重传

7.TCP流量控制

流量控制：接收方让发送方发慢点，是自己来得及接收（TCP采用滑动窗口机制实现）

通信过程中，接收方根据自己接收缓存的大小，动态的调整发送方的发送窗口大小，即通过设置确认报文段中的窗口字段来实现，发送方的发送窗口大小取接收窗口和拥塞窗口的最小值。

8.TCP拥塞控制

流量控制：流量控制一般是点到点，是发送方发送数据过快导致接收方无法接收。

拥塞控制：是一种全局性的控制，拥塞控制是在整个网络中，多个发送方发送数据过多，导致数据迟迟无法到达接收方。

接收窗口：接收方根据接收缓存设置的值，并告知发送方，反映接收方容量。

拥塞窗口：发送方根据自己估算的网络拥塞程度而设置的窗口值，反映网络当前容量。

拥塞控制的四种算法：

慢开始和拥塞避免：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-CI46Agym-1607517418620)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604280916231.png)]

cwnd：代表拥塞窗口的大小，cwnd=1规定发送窗口最大发送报文段的长度，一个最大报文段长度为MSS

一个传输轮次：发送了一批报文段并收到它们确认的时间，一个往返时延RTT，开始发送一批拥塞窗口内的报文段到开始发送下一批拥塞窗口内的报文段的时间

算法流程：如果没有检测到网络拥塞，拥塞窗口会呈现指数式增长，直到达到慢开始门限ssthresh，则开始启用拥塞避免算法，即加法增大，直到检测到网络拥塞，这时候直接把拥塞窗口值置为1，把慢开始门限置为拥塞时窗口值得一半，然后重新执行慢开始和拥塞避免算法

快重传和快恢复：

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uAdiCZ5s-1607517418622)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604281663815.png)]

算法流程：当检测到收到三个重复冗余ack后，立即执行快重传算法，并将门限值设为拥塞时得一半，拥塞窗口立即降为新的门限值，而不是降为1，这就是快恢复，然后执行拥塞避免算法

9.用户数据报协议UDP

不可靠，无连接，时延小，效率高，无拥塞控制，适合很多实时应用，UDP是面向报文的，适合一次性传输少量数据的网络应用，提供广播和多播服务。UDP接收来自应用层的报文不会分片，所以需要应用层传输过来的数据不要太大，否则网络层分组任务就很重，但是也不能太小，不然效率会低。

10.UDP数据报格式

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-GbNANkNa-1607517418623)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604130088149.png)]

UDP数据报的数据部分可有可无，所以最短为8个字节，也就是只包括首部

11.UDP校验

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-1BgFPoRx-1607517418624)(C:\Users\zfc\AppData\Roaming\Typora\typora-user-images\1604130189130.png)]

伪首部只有在计算检验和时才出现，不向上传递也不向下递交

17：封装UDP报文的IP数据报首部协议字段是17

UDP长度：UDP首部（8B）+数据部分（不包括伪首部）

UDP通过校验来提供差错检测，但它对差错恢复无能为力，他只能丢弃受损报文段，最多将受损的报文段交给应用程序并给出警告