这是我参与「第三届青训营 -后端场」笔记创作活动的第4篇笔记
为什么有了流量控制还需要拥塞控制
在网络拥堵时，如果继续发送大量的数据包，可能会导致数据包时延、丢包等，这时TCP会重传数据包，但是一旦重传会导致网络负担更重，使得时延、丢包更加明显，这种情况就会进入恶性循环从而导致网络负担更重。TCP不能无视网络上的事，当网络发生拥塞时，TCP会自我牺牲，降低发送的数据量。于是就有了拥塞控制，控制的目的就是避免发送方的数据填满整个网络。
如果 SYN 半连接队列已满，只能丢弃连接吗？
并不是这样，可以开启syncookies功能在不使用半连接队列的情况下接收连接，假设半连接队列已满，那么服务端对于新来的连接，根据当前状态计算出一个cookies放在己方发出的syn+ack报文中发出（其实就是seq字段），当客户端返回ack时，取出该值验证，如果合法，就说明连接建立成功放进全连接队列。
如何预防syn攻击
🍿增大半连接队列
🍿启用syncookies
🍿减少syn+ack重传次数
为什么说tcp是面向字节流的协议
首先说说udp，每个udp数据包都代表一个消息传输udp数据包时操作系统不会对数据包进行拆分，可以说upd是面向数据报的。
对于tcp而言，消息可能会被操作系统分组成个tcp报文，也可能几个消息合成一个tcp报文，假设现在客户端向服务器发送消息，客户端执行完send之后，操作系统并不会立即发送消息，消息只是从应用程序拷贝到了操作系统内核缓冲区，这时候客户端再发送一个消息也会拷贝到操作系统内核缓冲区中，那么有可能一个tcp报文包含两个消息，这就发生了粘包问题，所以不能认为一个消息对应一个tcp报文，正因为这样tcp时面向字节流的协议。
如何解决tcp粘包问题
🍿固定长度
🍿特殊字符作为边界
🍿自定义消息体
syn包什么情况下会被丢弃
🍿全连接队列满了：对于后续的连接直接抛弃
🍿半连接队列满了：半连接队列满了后续的连接将会被抛弃（使用syncookies的情况下即使半连接队列满了也不会抛弃syn）
\
