HTTP协议、TCP/IP协议集

HTTP协议：指客户端和服务器之间进行通讯时，需要的http报文， 这是一些列通讯的规范以及编码解码的格式定义，报文分为，请求报文和响应报文， 格式分为起始行、首部、主体。在早期的http1.1中采用ASCLL编码进行明文传输， 到HTTP/2的二进制帧传输。

Http通讯是需要TCP/IP进行承载的， 在通讯之间必要要建立tcp连接。

tcp连接：在连接之前， 首先需要准备工作TCB传输控制块， 包含了数据发送双方的socket信息以及装载数据的缓存区， 接着就是三次握手。

三次握手：重要的是控制位， 首先连接需要SYN=1的控制位代表是连接请求， 不携带数据，并且消耗调一个seq = x序列号。 因为tcp连接保证安全可靠， 所有每次请求必须得到回应， 即服务端会返回ack=x+1的确认号， ACK=1(表示确认号有效), 同时也发送SYN=1的请求连接控制位，消耗seq=y的序列号。这时双方都已经请求连接了，为什么客服端还需要发送一次确认号了， 首先通讯的安全保障是，双方都可以安全接收和发送信息， 一个来回， 只能代表客户端具备这些保障， 但是服务端并不能，他目前只具备接收保障， 所有客服端还需要发送一次确认号过去，让服务端也具备发送保障。 

客户端连接状态：CLOSE SYT-WAIT ESTABLELISHED

服务端连接状态：CLOSE LISTEN SYN-RCVD ESTABLELISHED

TCP连接协议的缺陷： DDOS分布式拒绝服务

SYN flood攻击时， 就是伪造了大量ip进行连接， 这是服务端响应确认后得不到回应，会重试3~5次，之后丢弃连接， 太多的半连接，会导致服务端无暇理睬正常连接从而导致拒绝服务

四次挥手：控制位FIN=1， 当客服端发起关闭连接后， 服务端接收到FIN关闭连接， 这个时候服务端也需要发送FIN关闭连接， 但是服务端可能还有数据没有处理完， 所以先发送ACK确认号， 之后服务端在发送FIN关闭连接确认好号， 从而客服端回应， 这也是为什么会从一次挥手！

当最后一次回应后， 客服端并不能立马进入关闭状态， 不然再也收不到服务端的重试，需要等待2msl， 一次传输消耗1msl, 如果服务端在1msl之后没有得到确认信息， 那么会进行重试。所以客服端要等待2msl之后没有收到重试才能关闭连接.

客服端状态：ESTABLELISHED  FIN-WAIT-1  FIN-WAIT-2 (TIME-WAIT 2MSL) CLOSED 

服务端状态：ESTABLELISHED CLOSE-WAIT LAST-ACK CLOSED

如果建立连接后， 客户端出现了故障，服务端怎么解决？

首先TCP设有一个保活计时器， 服务端没收到一个请求， 复位， 若一定时间没没有收到客服端请求， 将发送探测报文段， 每个75秒发送一个，10连发后， 没反应，关闭连接

传输原理：

TCP通过发送--响应（ACK确认）来确保传输的可靠性， 它时端到端之间的传输， 并且tcp传输是分段的， MSS（512， 主机536）, 每次发送按照顺序编号发送， 以便组装

TCP连接通过4个值来识别：源 IP 地址、 源端口号、 目的 IP 地址、 目的端口号

TCP如何保障数据的可靠性， 以及数据流控， 这俩点围绕着窗口滑动协议进行的：

窗口滑动协议： 同源发送方发送大量的数据包，如果第一个久久得不到确认即造成网络阻塞。那么我们允许发送发在停留等待确认时发送多个数据包， 我把每个数据包分为4组状态，不断得进行滑动即可， 1. 已确认已发送， 2. 已发送未确认 3. 未发送准备发送 4. 未发送未准备。 但是在这个过程中， 也许会发生Ack丢包， 也许是久久不能响应， 而我们得2状态区已满， 这个时候也会造成阻塞， 并且会进行超市重发/重传， 超时重传机制协议效率的一个关键参数是重传超时时间

HTTP的性能问题很大程度取决与TCP通道的性能！！！

HTTP事务时延的原因：

1. 域名解析 2.每天新的tcp连接时延 3. http报文的传输以及服务端处理报文 4. 会送响应报文

性能聚焦点区域：

1. tcp连接 （tcp分组传输）

2. tcp慢启动机制

慢启动限制了TCP端点任意时刻可以传输的分组数， 可以说是，刚开始的时候会先丢一个探测包，判断当前网络状况，然后从小到大增加阻塞窗口， 即每成功获取到一个分组，将拥有发送俩个分组的权限， “打开拥塞窗口”。 防止因特网的突然过载和拥塞。

3. tcp延迟确认算法

由于确认包很小， 所以tcp允许往相同方向的数据分组中进行携带， 为了让确实报文能够找到数据组， 有了延迟确认算法，一般100~200毫秒。 但是往往回传的时候，偏偏没这么多， 倒是掩饰很高

4. Nagle算法： 将小的数据包推积到一个全尺寸的组统一发送， 但是往往有很多http报文可能无法填满一个分组。造成等待那些永远不会到来的额外数据时延。

TCP串行事务的处理：

例如：一个网页需要加载很多很多的图片，以往的http协议， 可能导致，每个请求资源一个连接，并且还是串行。 效率是非常低的！ 

解决方案：(并行+持久化)

并行连接 ：同源下并行连接数是有限制的

持久化连接：依旧是串行， 但是共享一个连接 Connection: Keep-Alive 以避免慢启动的拥塞

管道话连接：（pipeline）技术， 可以多个请求同时发送， 但是不管那条请求响应块，都必须按照发送顺序执行， 也很容易造成头部阻塞， 只有幂等性请求才能管道话（就是当你刷新你的页面，不会带来影响就是幂等性请求）

HTTP/2的新特性下一章节！