【计算机网络】 传输层

UDP协议的特点

• UDP是无连接协议
• UDP不保证可靠的交付数据
• UDP是面向报文传输的
• UDP没有拥塞控制
• UDP的首部开销很小

TCP协议的特点

• TCP是面向连接的协议
• TCP的一个连接有两端（点对点通信）
• TCP提供可靠的传输服务
• TCP协议提供全双工通信
• TCP协议面向字节流的协议

TCP头部格式

• 序号：用于对字节流进行编号，一个字节一个序号，例如序号为 301，表示第一个字节的编号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。
• 确认号：占16位，期望收到的数据首字节序号，确认号为N，则表示N-1序号的数据都已收到，例如 B 正确收到 A 发送来的一个报文段，序号为 401，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 601，B 发送给 A 的确认报文段中确认号就为 601
• 数据偏移：占4位，单位为32位字，数据偏移首部的距离，实际上就是首部的长度
• TCP标记：占6位，每位各有不同的意义

• 窗口：占16位，窗口指明允许对方发送的数据量，之所以有窗口是因为接收方的数据缓存是有限的

可靠传输的基本原理

1.停止等待协议
无差错情况：发送方生成消息1发送出去，然后停止生成消息等待，接收到确认消息则继续生成消息2并发送出去，以此类推，接收方也是如此

有差错情况：

• 发送的消息在路上丢失了
• 确认的消息在路上丢失了
• 确认的消息很久才到达
  所以这个协议通过超时重传来实现可靠传输，每发送一个消息，便会设置一个超时定时器，超过时间没收到确认消息就重新发送，但是这也有缺点：信道的利用率不高。
  2.连续ARQ协议（自动重传请求）
  
  累计确认：
  收到某个位置的确认消息，则该序号之前的都确认收到了，滑动窗口向后移
  
  接收窗口只会对窗口内最后一个按序到达的字节进行确认，

如果收到的字节没有按序到达，则需要进行重传，如下图，不按序收到了25和27，但是23,24没有收到，所以要从23开始重传

但是如果一个字节一个字节重传效率太低了，所以这里引入了TCP的选择重传，可以在TCP选项里指定传输的范围，指定传输一段字节流

TCP流量控制

流量控制指让发送方发送效率不要太快，保证接收方来得及接收，
接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

坚持定时器：

当接收方改变滑动窗口大小并发送消息给发送方，但是如果消息丢失，则对于发送方，他会一直等待接收方的窗口调大，而接收方发送完窗口扩大的消息也会一直等待发送方发消息过来，这样双方就会陷入一个“死锁”状态，那么如何改变呢？
这里引入一个坚持定时器，当接收到窗口为0的消息时，则启动坚持定时器，坚持定时器每隔30秒发送一个窗口探测报文。

TCP拥塞控制

流量控制考虑点对点的通信量控制，
而拥塞控制考虑整个网络的控制，是全局性考虑，报文超时则认为是拥塞控制。
1.慢启动算法
由小到大逐渐增加发送数据量，每收到一个报文确认，就加一，指数增长，达到慢启动阈值，就启动拥塞避免算法。
2.拥塞避免算法
维护一个拥塞窗口的变量，只要网络不拥塞，就试着将拥塞窗口调大

TCP连接的建立

首先 接收方B 处于 LISTEN（监听）状态，等待客户的连接请求。

发送方A 向接收方 B 发送连接请求报文，SYN=1，ACK=0，选择一个初始的序号 x。

接收方B 收到连接请求报文，如果同意建立连接，则向发送方 A 发送连接确认报文，SYN=1，ACK=1，确认号为 x+1，同时也选择一个初始的序号 y。

发送方A 收到 接收方B 的连接确认报文后，还要向接收方 B 发出确认，确认号为 y+1，序号为 x+1。

接收方B 收到 发送方A 的确认后，连接建立。

为什么发送方要发出第三个确认报文

为了防止已经失效的连接请求报文发送到对方，引起错误
两次握手：

三次握手：

发送方发送的连接请求如果在网络中滞留，那么就会隔很长一段时间才能收到接收方端发回的连接确认。发送方等待一个超时重传时间之后，就会重新请求连接。但是这个滞留的连接请求最后还是会到达接收方，如果不进行三次握手，那么接收方就会打开两个连接，这就会造成错误。如果有第三次握手，发送方会忽略接收方之后发送的对滞留连接请求的连接确认，不进行第三次握手，因此就不会再次打开连接。

TCP连接的释放

发送方发送连接释放报文，FIN=1。

接收方 收到之后发出确认，此时 TCP 属于半关闭状态，接收方 能向 发送方 发送数据但是 发送方不能向 接收方 发送数据。

当 接收方 不再需要连接时，发送连接释放报文，FIN=1。

发送方 收到后发出确认，进入 TIME-WAIT 状态，等待 2 MSL（最大报文存活时间建议设置为30分钟）后释放连接。

接收方 收到 发送方 的确认后释放连接

四次挥手的原因

发送方 发送了 FIN 连接释放报文之后，接收方收到了这个报文，就进入了 CLOSE-WAIT 状态。这个状态是为了让接收方发送还未传送完毕的数据，传送完毕之后，接收方会发送 FIN 连接释放报文。

TIME_WAIT

发送方接收到接收方的 FIN 报文后进入此状态，此时并不是直接进入 CLOSED 状态，还需要等待一个时间计时器设置的时间 2MSL。这么做有两个理由：

**1.确保最后一个确认报文能够到达。如果 接收方 没收到 发送方 发送来的确认报文，那么就会重新发送连接释放请求报文，发送方 等待一段时间就是为了处理这种情况的发生。

2.等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

客户端突然挂掉了怎么办？

正常连接时，客户端突然挂掉了，如果没有措施处理这种情况，那么就会出现客户端和服务器端出现长时期的空闲。解决办法是在服务器端设置保活计时器，每当服务器收到客户端的消息，就将计时器复位。超时时间通常设置为2小时。若服务器超过2小时没收到客户的信息，他就发送探测报文段。若发送了10个探测报文段，每一个相隔75秒，还没有响应就认为客户端出了故障，因而终止该连接。

DOS攻击

DOS攻击：一台或多台计算机对受攻击服务器的某一个端口发送大量无关的UDP报文，导致整个通道内的正常服务无法进行。