vol.4运输层_为什么所有报文段都从网络中消失-CSDN博客

本文链接：https://blog.csdn.net/qq_43641886/article/details/106334185

TCP之流量控制(滑动窗口）和拥塞控制（拥塞控制的工作过程）
利用滑动窗口实现流量控制
发送窗口的选择滑动窗口和拥塞窗口的最小值
拥塞控制方法：慢开始拥塞避免快重传快恢复
浅析SYN FLOOD攻击原理
是在三次握手的第三次握手的时候，服务端需要客户端发送ack包进行回应时，他会耗费一定数量的系统内存来等待这个连接
首先是客户端发送一个SYN报文给服务端，然后这个服务端发送一个SYN-ACK包以回应客户端，接着，客户端就返回一个ACK包来实现一次完整的TCP连接。在服务端返回一个确认的SYN-ACK包的时候有个潜在的弊端，他可能不会接到客户端回应的ACK包。这个也就是所谓的半开放连接，服务端需要耗费一定的数量的系统内存来等待这个未决的连接，虽然这个数量是受限的，但是恶意者可以通过创建很多的半开放式连接来发动SYN洪水攻击。
syn cookie
SYN cookie就是用一个cookie来响应TCP SYN请求的TCP实现，根据上面的描述，在正常的TCP实现中，当服务端接收到一个SYN数据包，他返回一个SYN-ACK包来应答，然后进入TCP-SYN-RECV（半开放连接）状态来等待最后返回的ACK包。服务端用一个数据空间来描述所有未决的连接，然而这个数据空间的大小是有限的，所以攻击者将塞满这个空间。在TCP SYN COOKIE的执行过程中，当服务端接收到一个SYN包的时候，他返回一个SYN-ACK包，这个数据包的ACK序列号是经过加密的，也就是说，它由源地址，端口源次序，目标地址，目标端口和一个加密种子计算得出。然后服务端释放所有的状态。如果一个ACK包从客户端返回，服务端将重新计算它来判断它是不是上个SYN-ACK的返回包。如果这样，服务端就可以直接进入TCP连接状态并打开连接。从而使服务端避免守侯半开放连接。
为什么会出现粘包问题
UDP不是流协议，有消息边界，不存在粘包的问题。
因为TCP传输时时按照字节流进行
详情：
由于TCP协议本身的机制（面向连接的可靠地协议-三次握手机制）客户端与服务器会维持一个连接（Channel），数据在连接不断开的情况下，可以持续不断地将多个数据包发往服务器，但是如果发送的网络数据包太小，那么他本身会启用Nagle算法（可配置是否启用）对较小的数据包进行合并（基于此，TCP的网络延迟要UDP的高些）然后再发送（超时或者包大小足够）。那么这样的话，服务器在接收到消息（数据流）的时候就无法区分哪些数据包是客户端自己分开发送的，这样产生了粘包；服务器在接收到数据库后，放到缓冲区中，如果消息没有被及时从缓存区取走，下次在取数据的时候可能就会出现一次取出多个数据包的情况，造成粘包现象（确切来讲，对于基于TCP协议的应用，不应用包来描述，而应用流来描述），个人认为服务器接收端产生的粘包应该与linux内核处理socket的方式 select轮询机制的线性扫描频度无关
原因：
1)、可能是IP分片传输导致的，也可能是传输过程中丢失部分包导致出现的半包
2)、发送端出现：为了提高传输速度和效率, 把发送缓冲区中的数据拼为一个数据包发送到目的地( 比如:发送方需要等缓冲区满才发送出去，造成粘包)
3)、接收端出现：接收方不及时接收缓冲区的包，造成多个包接收。
解决办法：
1）、一个是采用分隔符的方式，即我们在封装要传输的数据包的时候，采用固定的符号作为结尾符
2）、另一种是采用在数据包中添加长度的方式，即在数据包中的固定位置封装数据包的长度信息（或可计算数据包总长度的信息），服务器接收到数据后，先是解析包长度，然后根据包长度截取数据包（此种方式常出现于自定义协议中），但是有个小问题就是如果客户端第一个数据包数据长度封装的有错误，那么很可能就会导致后面接收到的所有数据包都解析出错
一些字段解释
rwnd:接收端口，发送方的发送窗口不能超过接收方给出的接收窗口的数值，
cwnd:拥塞窗口大小
ssthresh:慢门槛门限
AIMD:加法增加，乘法减少
MSL:最长报文段寿命
RTT:记录一个报文段发出的时间，以及收到确认的时间，时间之差称为报文段往返时间
MSS:每一个TCP报文段中的数据字段的最大长度，不等于TCP报文段，要加上TCP首部字段才是，默认是536字节
为什么A在time-wait状态必须等待2MSL?
1）、为了保证A发送的最后一个ACk报文能够到达B
2）、使得本连接中持续的时间内所有产生的所有报文段都从网络中消失
为什么要规定最大报文段长度MSS?
如果使用较小的MSS长度，网络的利用率就低
MSS尽可能大一些，只要在IP层传输时不需要再分片就行
传输层