网络协议-TCP与UDP

贫僧法号云空丶

已于 2022-10-23 15:14:04 修改

阅读量1.3k

点赞数

分类专栏：网络协议文章标签：网络安全网络协议 tcp/ip udp

于 2022-10-23 01:53:35 首次发布

本文链接：https://blog.csdn.net/qq_43381463/article/details/127470224

版权

7 篇文章 0 订阅

订阅专栏

TCP协议

服务器是经历三个状态：初始下，服务器处于监听状态（listening），当服务器收到客户机的SYN报文后，进入SYN_RECV（半连接），服务器会使用一部分资源来保持一段时间，当收到客户机第三次握手后，进入establised状态（建立连接），就可以进行数据传输，当数据传输完成，会进行保持连接一段时间，是time-wait状态。如下图
为什么要三次握手而不是两次呢
- 为了防止已经失效的请求报文，重新传到服务器引起错误。假设是两次握手，客户端发起一次SYN请求后，由于网络阻塞没有发送到服务器；当客服端再次发送SYN请求，正常发送到服务器后，服务器响应SYN+ACK确认，建立起连接；这时客户端第一次发送的SYN请求因为网络恢复，重新传到服务器，服务器以为是客户端发起新的连接请求，再次响应SYN+ACK数据包；这时客户端认为是一个连接，服务端认为是两个连接，造成状态不一致
- 两次握手后建立连接，如果有主机恶意发送大量SYN请求，服务器收到后会响应SYN+ACK数据包，进入等待数据传输状态，会造成资源浪费，甚至服务器无法正常工作

数据传输
- 分包传输：设A向B分两次传输200字节
  - 主机A通过1个数据包发送100个字节的数据，数据包的 Seq 号设置为 1200。主机B为了确认这一点，向主机A发送 ACK 包，并将 Ack 号设置为 1301。
  - 为了保证数据准确到达，目标机器在收到数据包（包括SYN包、FIN包、普通数据包等）包后必须立即回传ACK包，这样发送方才能确认数据传输成功。
  - 此时 Ack 号为 1301 而不是 1201，原因在于 Ack 号的增量为传输的数据字节数。假设每次 Ack 号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确100字节全部正确传递还是丢失了一部分，比如只传递了80字节。因此按如下的公式确认 Ack 号：
```
Ack号 = Seq号 + 传递的字节数 + 1
```
  - 与三次握手协议相同，最后加 1 是为了告诉对方要传递的 Seq 号。
如何解决丢包，乱序
- 发送报文：序列号Seq、长度、数据内容
- 回复确认：Ack=Seq + 长度 +1
- 切割发送：根据序列号和长度重组
- 如果某一段报文丢失，或长度不同，则根据Ack重新传输

过程
- 客户端主动发起连接关闭请求，向服务端发送FIN包，客户端进入FIN-WAIT-1状态
- 服务器收到FIN包后，响应ACK报文，服务端进入CLOSE-WAIT状态，客户端收到ACK报文后进入FIN-WAIT-2状态
- 此时客户端和服务端还可以进行数据的收发
- 数据传输结束后，服务端发送FIN包，进入LAST-ACK状态
- 客户端收到FIN后，回复ACK包，进入TIME-WAIT状态，一段时间后断开连接
- 服务器收到ACK包后，直接关闭连接
为什么客户端收到FIN后会进入TIME-WAIT状态
- 为保证服务端已经收到ACK包。一旦发送完ACK后就立即断开连接，如果ACK包在传输过程中丢失，服务端会一直停留在LAST-ACK状态，等待ACK数据包。如果一直没有收到ACK数据包，服务端会重新发送FIN包，等待客户端进行确认