WEB入门浅谈14

网络原理

TCP/IP

状态

ESTABLISHED 连接建立成功，可以进行后续通信(类似打电话拨通状态)
LISTEN 服务器进入的状态，服务器准备就绪，允许客户端随时来建立连接(类似手机开机，信号良好)
CLOSE_WAIT 等待关闭状态，这个状态正常情况下存在时间较短，处在收到FIN时返回ACK到发送FIN的时间间隙中，一般情况下出现这个状态就表示代码出bug了，导致close没有及时调用。
TIME_WAIT 也是断开连接时的状态，谁主动断开连接谁就进入TIME_WAIT的状态(建立连接时，一定是客户端主动发送请求，而断开连接时，客户端和服务器都可以为主动)
TIME_WAIT存在的意义在于防止最后一个ACK发生丢包，因此在最后一个ACK发送之后进入TIME_WAIT状态，等待一定时间，这段时间发现对方没有重传FIN，就视为没有丢包，于是就真正释放连接，状态转为CLOSE

滑动窗口

TCP确实要保证可靠性，但是又要在保证可靠性的同时，还希望提高效率
确认应答机制如果在等待ACK到达之后在发送数据，效率就比较低。于是可以让发送方批量发送一批数据，再统一接收ACK。这一组数据能发送多少，这个数据量就叫做 窗口大小。在等待ACK时，每接收一个ACK，窗口的资源就释放出一个数据，随着对方ACK的到达，要等待的数据就会发生变化，同时也会发送新的数据出去。
这样做的好处就是把多条数据的等待ACK时间进行叠加，如此一来就大大的提高了传输数据的效率

---

关于丢包
若是ACK丢了包，则收到最后一个ACK就会返回一个信息(下一个是1998)则表示在1998之前所有的数据都以传输完毕，之前的ACK丢不丢都不影响了
若是数据丢了包，则会连续收到ACK(下一个是1998)表示1998这个数据已经丢失，后面无论传的是多少，ACK的结果都是一样(下一个是1998)此时就可以重新把1998数据再发送一次ACK就会更新至最新的数据。
这里的 重传机制 是比较精妙的，得益于确认序号的设计，保证了传输的效率是比较高的，重传的效率也是比较高的(没有重传重复/多余的数据)，这也叫做 快速重传机制。
滑动窗口的窗口大小影响传输数据速度的快慢，窗口越大，速度越快，窗口越小，速度越慢。但是相对的，窗口大了，占用的内存也就大了。而且不仅仅是内存，还有一些其它的因素也会影响到传输数据的快慢，如：
接收方处理数据的速度

流量控制

因此，我们应该根据接收方处理数据的能力来确定合适的 滑动窗口的窗口大小。则，发送方在开始时就有一个初始的窗口大小，然后发送一次数据，接收方返回一个ACK，这个ACK中不仅有确认序号，还有一个数据，表示 接收方缓冲区剩余空间大小 ，这样一来，我们就可以尽可能的保持发送方与接收方的速率达到一致，这样才能做到可靠的同时保证高速率，在ACK报文中，接收方会返回接收方剩余缓冲区的大小，发送方接下来就会以这个大小来决定窗口的大小，达到流量控制的效果
但是实际的网络环境没有这么理想，发送方的实际速率不仅仅要考虑接收方处理数据的能力，还需要考虑一些中间节点对数据的处理能力。

拥塞控制

由于网络环境比较复杂，不知道中间会经历多少个节点，所以，发送方会采取一个动态变化的过程，来试探出当前窗口大小为多少时才合适
发送方在初始时,会设置一个比较小的窗口大小发送数据试试，如果没有丢包，说明网络畅通。然后就开始尝试更大的窗口大小来进行数据传输，如果还没有丢包，就继续尝试更大的窗口来传输数据。如果丢包了，则缩小窗口大小。循环进行上述过程
滑动窗口的大小是由 流量控制机制 和 拥塞控制机制 来确定的
所以TCP一定会丢包，因此并不适合在一些对于效率非常高的场景，如网络游戏。而在这种场景下，我们一般使用一些其它的传输层协议

延迟应答

接收方在接收到数据时，并不立刻返回ACK，而是等待一段时间，然后再返回ACK。这样一来，返回的窗口大小就会尽可能的大，从而提升传输数据的效率
但是并不是每个包都会延迟应答，而是：
数量限制：每隔n个包，就延迟应答一次，
时间限制：超过最大延迟时间就应答一次

捎带应答

我们最常见的服务器通信模式一般是一问一答，除此之外还有多问一答，多问多答，一问多答。
ACK的时机是由内核来完成的，而发送响应是由服务器(代码)来完成的，本来是有时间间隔的，但是由于有延迟应答机制，所以可以减小这两个数据传输的时间间隔，从而满足捎带应答
应用程序在返回响应的时候，顺带把上个ACK数据一起传输回去，这就叫做捎带应答。这样一来，就减少了传输数据包的个数，降低了通信成本，提高了效率

面向字节流

把TCP传输的数据(应用层数据报)想象成水流一样。
应用层可以以字节为单位来读取/发送数据。
而面向字节流的核心就是TCP的缓冲区。
在三次握手后 主机A和主机B 就各自在内核里维护一对缓冲区，分别为发送缓冲区和接收缓冲区。
主机A给主机B发送一个消息，主机A先调用系统提供的send方法，把消息放在发送缓冲区里。而缓冲区的数据什么时候发送出去，由内核来决定。等A发送出去后，数据通过网络到达主机B的接收缓存区，主机B通过系统提供的recv方法来从缓冲区中读取数据
当发送方一次发送了多组数据，接收方从缓冲区读取数据时，可能会出现歧义（缓冲区的数据堆在一起，分不清哪里是哪个数据报，这个问题称为 粘包问题 这是面向字节流的缺陷，并不是TCP的缺陷。）

TCP异常处理

进程中止：相当于把程序停止运行，进程的结束，就会导致 四次挥手 。仍然可以发送FIN，和正常关闭没有区别
机器重启：相当于进程终止，机器的关机就会导致杀死进程，就会导致 四次挥手 ，但是不一定完成四次挥手，接收方发送的FIN可能会没有ACK回应，但是等待一段时间后，接收方也会进入close状态
断网/停电：(发送方)发现对方没有ACK时，就会触发超时重传，达到一定次数，就会重建连接，如果还是没有回应，就会释放连接。(接收方)发现对方没有反应时，就会触发 保活机制 (TCP内置的保活定时器，每过一段时间就会发送数据验证是否正常巩工作)，如果还没回应，就会释放连接

总结

TCP的一些机制

1. 确认应答
2. 超时重传
3. 连接管理
4. 滑动窗口
5. 流量控制
6. 拥塞控制
7. 延时应答
8. 捎带应答
9. 面向字节流
10. 异常处理
    其中12356 10保证可靠性，478保证效率，9为代码可能出现粘包问题

补充

TIME_WAIT 等待的时间为 2 MSL ，MSL 表示网络中，两台主机之间传输数据的最大时间间隔

---

解决粘包问题 设计应用层协议的时候，能够显式的区分出来数据报的边界
1.在应用层显式的指定包的长度
2.显式的指定包与包之间的分隔符
一个搭配TCP协议使用的应用层协议，必须具备1或2或1 2这两点
在HTTP协议中就用到了1 2 两种。

---

负载均衡机制
如果某个网站的访问量较大，服务器处理不过来时就会触发，由于每个主机能处理的请求是有限的
网关/反向代理就会把请求分发给各个主机(每个主机都是等价的)，每个主机再去处理请求，此时就存在一些没有请求的主机，那么就会触发保活机制来验证主机是否正常工作
负载均衡还有一个很大的好处就是不重启服务器的情况下，对服务器进行重启/升级