文章总结（2）—网络-CFANZ编程社区

在连接的复用上：
HTTP/1.x使用Connection:Keep-Alive保持长连接，但是浏览器在同一时间针对同一域名的请求由一定数量限制，超过限制数目的请求就会被阻塞。
HTTP/2使用单一长连接多路复用，虽然只有一条TCP连接，但是逻辑上分为多个Stream。将信息分成二进制的流，可以发起多次的请求响应。
格式：
HTTP/1传输的是文本格式，而HTTP/2传输的是二进制帧的格式；
HTTP/2会对消息头进行HPACK压缩。会节省带宽资源。

HTTP/2支持Server Push，即缓存推送。主要思想是：当客户端请求资源X时，服务器知道它很可能也需要资源Z的情况下，主动将资源Z推送给客户端。无需客户端再次请求。

对称加密：加密使用的秘钥和解密使用的秘钥是相同的。特点是算法公开，计算量小，加密效率高。算法一般是DES。

非对称加密：需要两个密钥，公钥和私钥，公钥和私钥是一对。用法一般是公钥加密，私钥解密；私钥签名，公钥解签。特点是：保密性好，但是算法强度复杂。算法一般是RSA。

数字证书是Https实现安全传输的关键，它是由权威的CA机构颁发。https加密过程，一般会采取两种算法进行加密：对称加密算法和非对称加密。

浏览器请求https连接，服务器发送证书；
浏览器验证收到的证书。
2.1 判断证书是否受信任：根据证书内容回去浏览器寻找内置的根证书，若未找到根证书，代表该机构不受信任。
2.2 判断该证书是否被篡改：获取根证书的公钥，去解密证书<指纹>（非对称加密），获取<指纹>中的hash值，然后根据收到证书信息内容再次生成一个hash值，判断信息是否被篡改。
2.3 判断证书是否被替换：验证是否为目标服务器发送的证书，检查证书<使用者>属性是否和我们请求的url是否相同。
若证书验证成功，生成一个对称加密的密钥，使用收到证书的<公钥>进行加密，然后发送给服务器。
即使加密串被拦截，拦截者没有私钥，信息也不会被泄漏。目标服务器收到加密串后，使用证书私钥解密，获取对称加密的密钥。
而后浏览器和服务器使用对称加密进行数据传输。

总结：浏览器在建立https连接时，服务器会发送证书。浏览器使用内置的根证书的公钥去验签证书中的指纹信息（非对称加密）。证书验证完毕后，浏览器生成一个对称加密的密钥，使用受到证书的公钥进行加密。而后浏览器和服务器使用对称加密进行数据传输。

使用SYN，解决网络包乱序，使用ACK解决不丢包的问题

三次握手是为了建立可靠的连接，TCP规定通信双方都必须维护一个序列号，保证数据在网络传输中不丢包。三次的目的就是通信方法交换初始化序列号并相互确定的过程。

不可以，三次握手是为了建立可靠的连接，TCP通信双方都必须维护一个序列号，已确保不丢包。三次握手的过程是通信双方交换初始化序列号，并确定对方已经收到的过程。

如果只是两次握手，至多只有发起方的序列号被确定，另一方的序列号得不到确定。

只进行两次握手时，客户端掉线，server未收到client返回的ACK，那么serevr会进行重发。在Linux环境下默认重发5次。可能会造成SYN Flood攻击（即给服务器发送一个SYN就下线）服务器默认会进行5次重发才会断开连接，这样攻击者就可以把服务器syn的队列耗尽。

Linux提供tcp_syncookies参数来解决，当SYN队列满了，TCP会通过源地址新打造一个cookies发送，若是攻击不会有响应。若是正常连接则会将SYN cookies发过来，然后服务器就可以通过cookie建立连接（即使不在SYN队列）。但是注意不能使用syn_cookie应对正常请求。

对于正常请求，应该跳转TCP参数。减少重试次数、增加SYN连接数、若处理不过来直接拒绝连接来处理。

服务器收到客户端发送的关闭请求后，会立即发出ACK。服务端会通知应用进程，由应用进程来决定是否关闭连接。TCP无权将FIN和ACK一同发送。

因为SpringBoot配置文件中配置了该属性server.connection-timeout: 8000。即服务端保持链接的最长时间。当客户端使用http长链接进行通信时，服务在8秒的时候回发送FIN。当客户端依旧有数据达到时，客户端会发起RESET。

客户端发送一个SYN段，并指明客户端的初始序列号，即ISN(c).
服务端发送自己的SYN段作为应答，同样指明自己的ISN(s)。为了确认客户端的SYN，将ISN(c)+1作为ACK数值。这样，每发送一个SYN，序列号就会加1. 如果有丢失的情况，则会重传。
为了确认服务器端的SYN，客户端将ISN(s)+1作为返回的ACK数值。

1、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付
3、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小，只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

网络基础：TCP协议-如何保证传输可靠性

1. 校验和
计算方式：在数据传输的过程中，将发送的数据段都当做一个16位的整数。将这些整数加起来。并且前面的进位不能丢弃，补在后面，最后取反，得到校验和。
发送方：在发送数据之前计算检验和，并进行校验和的填充。
接收方：收到数据后，对数据以同样的方式进行计算，求出校验和，与发送方的进行比对。
注意：如果接收方比对校验和与发送方不一致，那么数据一定传输有误。但是如果接收方比对校验和与发送方一致，数据不一定传输成功。

2. 连接管理
三次握手和四次挥手保证建立可靠连接。
3. 序列号/确认应答
序列号：tcp传输时将每个字节的数据都进行编号。
确认应答：tcp传输过程中，每次接收方收到数据后，都会对传输方进行确认应答，也就是发送ACK。这个ACK报文中带有对应的确认序列号，告诉发送方，接收到了哪些数据，下一次的数据从哪里发。
4. 超时重传
发送方发送完数据，迟迟没有等到接收方的ACK报文？
有两种情况：（1）数据在传输过程中丢了，接收方没有收到；
（2）接收方收到了数据，但是发送的ACK由于网络原因丢了；
超时重试就是为了解决这个问题。发送方在发送完数据后等待一个时间，时间到达没有接收到ACK报文，那么会对刚才发送的数据进行重新发送。如果是第一个原因，接收方收到二次重发的数据后，便进行ACK应答。如果是第二个原因，接收方发现接收的数据已存在，那么直接丢弃，依旧发送ACK。

5. 流量控制（滑动窗口控制）
接收方收到数据后，进行处理。但是如果发送端的发送速度太快，导致接收端的结束缓存区很快被填满，那么发送端后来发送的数据都会丢弃。而TCP根据接收端对数据的处理能力，决定发送端的发送速度，这个机制就是流量控制。
TCP协议的报头信息中，有一个16位字段的窗口大小。窗口大小的内容实际上就是接收端接收数据缓冲区的剩余大小。接收端会在确认应答发送ACK报文时，将自己的即时窗口大小填入，并跟随ACK报文一起发送过去。发送方根据ACK报文里的窗口大小的值的改变而改变自己发送速度。
6. 拥塞控制；
TCP传输过程中，发送端开始发送数据的时候，如果刚开始就发送大量数据，那么就可能造成一些问题。网络可能在开始的时候就很拥堵，如果给网络中扔出大量数据，这个拥堵就会加剧。拥堵的加剧会产生大量丢包，就会产生大量超时重传，严重影响传输。
所以TCP引入慢启动的机制，在开始发送数据时，先发送少量数据探路。探清当前网络状态如何，在决定多大的速度进行传输。引入拥塞窗口概念。发送刚开始定义拥塞窗口为1，每次收到ACK应答，拥塞窗口加1。在发送数据之前，首先将拥塞窗口与接收端反馈的窗口大小对比。取较小的值作为实际发送的窗口。

拥塞窗口的增长是指数级别的。慢启动的机制只是说明在开始的时候发送的少，发送的慢，但是增长的速度是非常快的。为了控制拥塞窗口的增长，不能使拥塞窗口单纯的加倍。

拥塞窗口存在阈值，当拥塞窗口大小超过阈值时，不能再按照指数来增长，而是线性增长。在慢启动开始的时候，慢启动阈值等于窗口最大值，一旦造成网络拥塞，发送超时重传时，慢启动阈值会为原来的一半（这里的原来是指发生网络阻塞时拥塞窗口的大小），同时拥塞窗口重置为1。

那么发送方发送完毕后等待的时间是多少呢？如果这个等待的时间过长，那么会影响TCP传输的整体效率，如果等待时间过短，又会导致频繁的发送重复的包。如何权衡？

由于TCP传输时保证能够在任何环境下都有一个高性能的通信，因此这个最大超时时间（也就是等待的时间）是动态计算的【阶梯增长】。当累计到一定重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

在Linux中（BSD Unix和Windows下也是这样）超时以500ms为一个单位进行控制，每次判定超时重发的超时时间都是500ms的整数倍。重发一次后，仍未响应，那么等待2*500ms的时间后，再次重传。等待4*500ms的时间继续重传。以一个指数的形式增长。累计到一定的重传次数，TCP就认为网络或者对端出现异常，强制关闭连接。

重放攻击本质是二次请求。攻击者发送一个目的主机已接收的包，来达到欺骗系统的目的。