网络协议(四)

简述 HTTP 的 keepalive 的原理和使用场景

当使用 Keep-Alive 模式时，Keep-Alive 功能使客户端到服务器端的连接持续有效。

HTTP1.0 KeepAlive支持的数据交互流程如下：

a)Client发出request，其中该request的HTTP版本号为1.0。同时在request中包含一个header：”Connection： keep-alive”。

b)Web Server收到request中的HTTP协议为1.0及”Connection： keep-alive”就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive”。同时不会关闭已建立的tcp连接。

c)Client收到Web Server的response中包含”Connection： keep-alive”，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）

HTTP1.1 KeepAlive支持的数据交互流程如下：

a)Client发出request，其中该request的HTTP版本号为1.1。

b)Web Server收到request中的HTTP协议为1.1就认为是一个长连接请求，其将在response的header中也增加”Connection： keep-alive”。同时不会关闭已建立的tcp连接。

c)Client收到Web Server的response中包含”Connection： keep-alive”，就认为是一个长连接，不close tcp连接。并用该tcp连接再发送request。（跳转到a)）

简述在四层和七层网络协议中负载均衡的原理

二层负载均衡会通过一个虚拟 MAC 地址接收请求，然后再分配到真实的 MAC 地址；

三层负载均衡会通过一个虚拟 IP 地址接收请求，然后再分配到真实的 IP 地址；

四层通过虚拟 IP + 端口接收请求，然后再分配到真实的服务器；

七层通过虚拟的 URL 或主机名接收请求，然后再分配到真实的服务器。

所谓的四到七层负载均衡，就是在对后台的服务器进行负载均衡时，依据四层的信息或七层的信息来决定怎么样转发流量。

比如四层的负载均衡，就是通过发布三层的 IP 地址（VIP），然后加四层的端口号，来决定哪些流量需要做负载均衡，对需要处理的流量进行 NAT 处理，转发至后台服务器，并记录下这个 TCP 或者 UDP 的流量是由哪台服务器处理的，后续这个连接的所有流量都同样转发到同一台服务器处理。

七层的负载均衡，就是在四层的基础上（没有四层是绝对不可能有七层的），再考虑应用层的特征，比如同一个 Web 服务器的负载均衡，除了根据 VIP 加 80 端口辨别是否需要处理的流量，还可根据七层的 URL、浏览器类别、语言来决定是否要进行负载均衡。

简述 TCP 半连接发生场景

发生在TCP三次握手中
如果A向B发起链接，B也按照正常情况响应了，但是A不进行三次握手，这就是半连接。
半连接攻击：半连接，会造成B分配的内存资源就一直这么耗着，直到资源耗尽。（SYN攻击）

什么是 SYN flood，如何防止这类攻击？

SYN Flood顾名思义就是用洪水一样的SYN报文进行攻击。

在连接超时之前，服务器会一直等待ACK报文，此时该连接状态为半开放连接（也被称为半连接）。半连接会占用服务器的连接数，当连接数被占满时，服务器就无法提供正常的服务了。

TCP首包丢弃:
该算法利用了TCP/IP协议的重传特性，来自某个源IP的第一个syn包到达时被直接丢弃并记录状态(五元组)，在该源IP的第2个syn包到达时进行验证，然后放行。

当防御设备接到一个IP地址的SYN报文后:

接受到syn报文 -> 简单比对该IP是否存在于白名单中: 存在则转发到后端，否则进行第2步
不存在于白名单中 -> 检查是否是该IP在一定时间段内的首次SYN报文：不是则进行第3步，是则进行第5步
不是首次SYN报文 -> 检查是否重传报文：是重传则转发并加入白名单，不是则丢弃并加入黑名单
是首次SYN报文 -> 丢弃并等待一段时间以试图接受该IP的SYN重传报文，等待超时则判定为攻击报文加入黑名单。

cookie源认证
原理是syn报文首先由DDOS防护系统来响应syn_ack。带上特定的sequence number （记为cookie）。真实的客户端会返回一个ack 并且Acknowledgment number 为cookie+1。而伪造的客户端，将不会作出响应。这样我们就可以知道那些IP对应的客户端是真实的，将真实客户端IP加入白名单。下次访问直接通过，而其他伪造的syn报文就被拦截。

简述 HTTP 报文头部的组成结构

1、开始行
在请求报文称为请求行，在响应报文称为状态行。
2、首部行
用来说明浏览器、服务器、或报文主体的一些信息。
3、实体主体
请求报文一般不会有这个字段，而响应报文一般有，但也可以没有。

为什么需要序列化？有什么序列化的方式？

对象的序列化是指通过某种方法把对象以字节序列的形式保存起来。反之通过字节序列得到原对象就是反序列化。

描述数据的传输格式，这样可以方便自己组织数据传输格式，以至于避免一些麻烦及错误
如果是跨平台的序列化，则发送方序列化后，接收方可以用任何其支持的平台反序列化成相应的版本，比如 Java序列化后

序列化的方式

Java原生序列化:只要对象实现了Serializable接口，该对象就可以进行序列化

Java原生序列化方式，主要由ObjectInputStream和ObjectOutputStream实现，他们可以直接装饰文件I/O（RandomAccessFile）或者网络I/O（Socket），来实现将对象存储到文件或者在网络中传输。不过，还有几点需要注意：

序列化对象需实现Serialization接口
static属性不能被序列化，序列化保存对象的状态，static属于类状态
transient修饰的不能被序列化
版本号serialVersionUID
- 版本号一致，新增字段不影响反序列化对象
- 版本号不一致，影响反序列化对象，将报错

JSON是一种轻量级的数据交换格式。如Redis存储对象时，使用JSON格式，使数据支持跨平台、可读性也更强。
XML是一种很常见的数据保存方式。SOAP是基于XML为序列化和反序列化协议的结构化消息传递协议。
Kryo是一个快速有效的Java二进制对象图序列化框架。主要有序列化反序列化更高效、序列化之后字节数据更小、更易用等特点。

TCP 如何实现数据有序性？

主机每次发送数据时，TCP就给每个数据包分配一个序列号并且在一个特定的时间内等待接收主机对分配的这个序列号进行确认
如果发送主机在一个特定时间内没有收到接收主机的确认，则发送主机会重传此数据包。
接收主机利用序列号对接收的数据进行确认，以便检测对方发送的数据是否有丢失或者乱序等
接收主机一旦收到已经顺序化的数据，它就将这些数据按正确的顺序重组成数据流并传递到高层进行处理。

简述 HTTP 短链接与长链接的区别

短连接

连接->传输数据->关闭连接
比如HTTP是无状态的的短链接，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。
因为连接后接收了数据就断开了，所以每次数据接受处理不会有联系。这也是HTTP协议无状态的原因之一。

长连接

连接->传输数据->保持连接 -> 传输数据-> ………..->直到一方关闭连接，多是客户端关闭连接。
长连接指建立SOCKET连接后不管是否使用都保持连接，但安全性较差。

什么时候用长连接，短连接？

长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况，。每个TCP连接都需要三步握手，
这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都
不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接，如果
用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。

而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网
站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成
千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频
繁操作情况下需用短连好。