TCP连接管理

与TCP连接管理相关的攻击

SYN泛洪是一种TCP拒绝服务攻击,在这种攻击中一个或多个恶意的客户端产生一系列TCP连接尝试(SYN报文段),并将它们发送给一台服务器,它们通常采用“伪造”的(例如,随机选择)源IP地址。服务器会为每一条连接分配一定数量的连接资源。由于连接尚未完全建立,服务器为了维护大量的半打开连接会在耗尽自身内存后拒绝为后续的合法连接请求服务。

其解决方法是使用SYN cookies：
服务器在接收到SYN请求时，不立刻设置内存准备给TCP连接，而是将状态编码并存在服务器返回的SYN+ACK报文的序列号字段，当接收到客户的ACK时才分配内存

SYN Cookies 是根据以下规则构造的初始序号：
令t为一个缓慢递增的时间戳（通常为time()>>6，提供 64 秒的分辨率）
令m为服务器会在 SYN 队列条目中存储的最大分段大小（Maximum segment size）
令s为一个加密散列函数对服务器和客户端各自的 IP 地址和端口号以及t进行运算的结果。返回得到的数值s必须是一个24位值
初始TCP序号，也就是所谓的SYN cookie，按照如下算法得到：
头五位：tmod32
中三位：m编码后的数值
末24位：s本身
注：由于m必须用 3 位进行编码，服务器在启用了 SYN Cookie 时只能为m发送八种不同的数值

TCP沾包

TCP粘包就是指发送方发送的若干包数据到达接收方时粘成了一包，从接收缓冲区来看，后一包数据的头紧接着前一包数据的尾，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。
造成沾包的原因：
发送方：
TCP默认使用Nagle算法（主要作用：减少网络中报文段的数量），而Nagle算法主要做两件事：
1、只有上一个分组得到确认，才会发送下一个分组
2、收集多个小分组，在一个确认到来时一起发送
Nagle算法造成了发送方可能会出现粘包问题

接收方：
TCP接收到数据包时，并不会马上交到应用层进行处理，或者说应用层并不会立即处理。实际上，TCP将接收到的数据包保存在接收缓存里，然后应用程序主动从缓存读取收到的分组。这样一来，如果TCP接收数据包到缓存的速度大于应用程序从缓存中读取数据包的速度，多个包就会被缓存，应用程序就有可能读取到多个首尾相接粘到一起的包。

何时需要处理沾包：
如果发送方发送的多组数据本来就是同一块数据的不同部分，比如说一个文件被分成多个部分发送，这时当然不需要处理粘包现象，如果多个分组毫不相干，甚至是并列关系，那么这个时候就一定要处理粘包现象了

发送方：
关闭Nagle算法

接收方：
接收方无法处理沾包问题

应用层：
1、设置固定格式——每条数据都有固定的开头符合结束符，这种方法简单，但是需要注意保证数据内部没有开始符合结束符
2、明确长度——在发送方发送数据的时候就包含数据的长度，应用层按长度读取就好

UDP是否会沾包：
TCP为了保证可靠传输并减少额外的开销（每次发包都要验证），采用了基于流的传输，基于流的传输不认为消息是一条一条的，是无保护消息边界的（保护消息边界：指传输协议把数据当做一条独立的消息在网上传输，接收端一次只能接受一条独立的消息）。

UDP则是面向消息传输的，是有保护消息边界的，接收方一次只接受一条独立的信息，所以不存在粘包问题。

举个例子：有三个数据包，大小分别为2k、4k、6k，如果采用UDP发送的话，不管接受方的接收缓存有多大，我们必须要进行至少三次以上的发送才能把数据包发送完，但是使用TCP协议发送的话，我们只需要接受方的接收缓存有12k的大小，就可以一次把这3个数据包全部发送完毕。

TCP心跳包

所谓的心跳包就是（探测性的）数据包，之所以叫心跳包是因为：它像心跳一样每隔固定时间发一次，以此来告诉服务器，这个客户端还活着。事实上这是为了保持长连接，至于这个包的内容，是没有什么特别规定的，不过一般都是很小的包，或者只包含包头的一个空包。

采用TCP连接的C/S模式软件，连接的双方在连接空闲状态时，如果任意一方意外崩溃、宕机、网线断开或路由器故障，另一方无法得知TCP连接已经失效，除非继续在此连接上发送数据导致错误返回。很多时候，这不是我们需要的。我们希望服务器端和客户端都能及时有效地检测到连接失效，然后优雅地完成一些清理工作并把错误报告给用户。

UDP如何实现可靠传输

模仿TCP即可，加入确认机制，重传机制，滑动串口，拥塞控制等

cookie和session的区别

cookie是存在客户电脑中的，包含唯一的id和有效时间等属性

session存在服务器中，且有声明周期，一般为20分钟，关闭浏览器或超过20分钟无动作会导致session被删除，且session对每个客户也分配了唯一的JSESSIONID，这个东西也存在cookie里，也就是说没有cookie的话session也无法使用
session存了

状态码

状态码是由3位数组成，第一个数字定义了响应的类别，且有五种可能取值:

1xx：指示信息–表示请求已接收，继续处理。

2xx：成功–表示请求已被成功接收、理解、接受。

3xx：重定向–要完成请求必须进行更进一步的操作。

4xx：客户端错误–请求有语法错误或请求无法实现。

5xx：服务器端错误–服务器未能实现合法的请求。