HTTP 1.1 HTTP 2.0

HTTP站在TCP之上

理解http协议之前一定要对TCP有一定基础的了解。HTTP是建立在TCP协议之上，TCP协议作为传输层协议其实离应用层并不远。HTTP协议的瓶颈及其优化技巧都是基于TCP协议本身的特性。比如TCP建立连接时三次握手有1.5个RTT（round-trip time）的延迟，为了避免每次请求的都经历握手带来的延迟，应用层会选择不同策略的http长链接方案。又比如TCP在建立连接的初期有慢启动（slow start）的特性，所以连接的重用总是比新建连接性能要好。

基于tcp的长链接

http long-polling

http streaming

web socket

移动端HTTP现状

iOS平台

iOS系统是从iOS8开始才通过NSURLSession来支持SPDY的，iOS9+开始自动支持http2.0。实际上apple对http2.0非常有信心，推广力度也很大。新版本ATS机制默认使用https来进行网络传输。APN（Apple Push Notifiction）在iOS9上也已经是通过http2.0来实现的了。iOS9 sdk里的NSURLSession默认使用http2.0，而且对开发者来说是完全透明的，甚至没有api来知道到底是用的哪个版本的http协议。

对于开发者来说到底怎么去配置最佳的http使用方案呢？在我看来，因app而异，主要从两方面来考虑：一是app本身http流量是否大而且密集，二是开发团队本身的技术条件。http2.0的部署相对容易很多，客户端开发者甚至不用做什么改动，只需要使用iOS9的SDK编译即可，但缺点是http2.0只能适用于iOS9的设备。SPDY的部署相对麻烦一些，但优点是可以兼顾iOS6+的设备。iOS端的SPDY可以使用twitter开发的CocoaSPDY方案，但有一点需要特别处理：

由于苹果的TLS实现不支持NPN，所以通过NPN协商使用SPDY就无法通过默认443端口来实现。有两种做法，一是客户端和server同时约定好使用另一个端口号来做NPN协商，二是server这边通过request header智能判断客户端是否支持SPDY而越过NPN协商过程。第一种方法会简单一点，不过需要从框架层将所有的http请求都map到另一个port，url mapping可以参考我之前的一篇文章。twitter自己的网站twitter.com使用的是第二种方法。

浏览器端（比如Chrome），server端（比如nginx）都陆续打算放弃支持spdy了，毕竟google官方都宣布要停止维护了。spdy会是一个过渡方案，会随着iOS9的普及会逐步消失，所以这部分的技术投入需要开发团队自己去衡量。

Android平台

android和iOS情况类似，http2.0只能在新系统下支持，spdy作为过渡方案仍然有存在的必要。

对于使用webview的app来说，需要基于chrome内核的webview才能支持spdy和http2.0，而android系统的webview是从android4.4（KitKat）才改成基于chrome内核的。

对于使用native api调用的http请求来说，okhttp是同时支持spdy和http2.0的可行方案。如果使用ALPN，okhttp要求android系统5.0+(实际上，android4.4上就有了ALPN的实现，不过有bug，知道5.0才正式修复)，如果使用NPN，可以从android4.0+开始支持，不过NPN也是属于将要被淘汰的协议。

TCP是面向连接的，可靠的字节流的协议。连接时需要三次握手，断开时需要四次挥手。这是因为TCP是全双工的，数据可以在两端传递，所以断开时都需要在每端单独进行关闭，一方向的关闭通常是半关闭的，所以一端关闭时需要发送FIN来终止连接，收到后需要确认ACK给发送端。

TCP数据在IP数据报中的封装为20字节的IP首部加上20字节TCP首部和TCP数据。

TCP/IP协议族

1.Frame: 物理层 比特流

2.Ethernet II:数据链路层 以太网帧头部信息

3.IP网络层  IP Packet 头部信息

4.传输层 TCP Data Segment 头部信息

5.应用层 HTTP

网络层次划分为 标准的OSI七层模型，还有 TCP/IP四层协议 以及 TCP/IP五层协议。如图：

Wireshark下

TCP协议

  TCP是一种面向连接的、可靠的基于字节流的传输层通信协议。TCP将用户数据打包成报文段，它发送后启动一个定时器，另一端收到的数据进行确认，对失序的数据重新排序、丢弃重复数据。

TCP报文首部，如下图所示：

16位源端口号

16为目的端口号

Sequence number – 序号

Acknowledgment number – 确认号

Flags – 标志位

—Urgent pointer 紧急指针位

— Acknowledgment 确认位

— Push 急迫位

— Reset 重置位

— Syn 同步位

— Fin 终止位

a. 第一次握手标志位

localhost Seq=0 -> 博客地址

从标志位看出，同步位有值，在做请求（SYN）：Syn 同步位为1

b. 第二次握手标志位

博客地址 Seq=0 Ack=1 -> localhost

从标志位看出，确认位、同步位有值，在做应答（SYN+ACK）：Syn 同步位为 1 、Acknowledgment 确认位为 1

c. 第三次握手标志位

localhost Seq=1 Ack=1 ->  （注: Seq=Seq+1）

从标志位看出，只有确认位有值，在做再次确认（SYN）：Acknowledgment 确认位为 1

所以，一个完整的三次握手就是：请求（SYN） — 应答（SYN+ACK） — 再次确认（SYN）。

三次握手：

为什么需要“三次握手”

在谢希仁著《计算机网络》第四版中讲“三次握手”的目的是“为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误”。在另一部经典的《计算机网络》一书中讲“三次握手”的目的是为了解决“网络中存在延迟的重复分组”的问题。这两种不同的表述其实阐明的是同一个问题。

谢希仁版《计算机网络》中的例子是这样的，“已失效的连接请求报文段”的产生在这样一种情况下：client发出的第一个连接请求报文段并没有丢失，而是在某个网络结点长时间的滞留了，以致延误到连接释放以后的某个时间才到达server。本来这是一个早已失效的报文段。但server收到此失效的连接请求报文段后，就误认为是client再次发出的一个新的连接请求。于是就向client发出确认报文段，同意建立连接。假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据。但server却以为新的运输连接已经建立，并一直等待client发来数据。这样，server的很多资源就白白浪费掉了。采用“三次握手”的办法可以防止上述现象发生。例如刚才那种情况，client不会向server的确认发出确认。server由于收不到确认，就知道client并没有要求建立连接。”。 主要目的防止server端一直等待，浪费资源。

四次挥手：

流量控制（滑动窗口协议）

传输数据的时候，如果发送方传输的数据量超过了接收方的处理能力，那么接收方会出现丢包。为了避免出现此类问题，流量控制要求数据传输双方在每次交互时声明各自的接收窗口「rwnd」大小，用来表示自己最大能保存多少数据，这主要是针对接收方而言的，通俗点儿说就是让发送方知道接收方能吃几碗饭，如果窗口衰减到零，那么就说明吃饱了，必须消化消化，如果硬撑的话说不定会大小便失禁，那就是丢包了。

flow control

接收方和发送方的称呼是相对的，如果站在用户的角度看：当浏览网页时，数据以下行为主，此时客户端是接收方，服务端是发送方；当上传文件时，数据以上行为主，此时客户端是发送方，服务端是接收方。

1、流量控制是管理两端的流量，以免会产生发送过块导致收端溢出，或者因收端处理太快而浪费时间的状态。用的是：滑动窗口，以字节为单位

2、窗口有3种动作：展开（右边向右），合拢（左边向右），收缩（右边向左）这三种动作受接收端的控制。

合拢：表示已经收到相应字节的确认了

展开：表示允许缓存发送更多的字节

收缩（非常不希望出现的，某些实现是禁止的）：表示本来可以发送的，现在不能发送；但是如果收缩的是那些已经发出的，就会有问题；为了避免，收端会等待到缓存中有更多缓存空间时才进行通信。

发端窗口的大小取决于收端的窗口大小rwnd（TCP报文的窗口大小字段）和拥塞窗口大小cwnd（见拥塞控制）

发端窗口大小 = min{ rwnd , cwnd };

3、关闭窗口：窗口缩回有个例外，就是发送rwnd=0表示暂时不愿意接收数据。这种情况下，发端不是把窗口收缩，二是停止发送数据。（为了比避免死锁，会用一些探测报定时发送试探，见定时器一节）

4、问题：某些时候，由于发端或收端的数据很慢，会引起大量的1字节数据痛惜，浪费很多资源。

（1）、发端的进程产生数据很慢时候，时不时的来个1字节数据，那么TCP就会1字节1字节的发送，效率很低。

解决方法（Nagle算法）：

a、将第一块数据发出去

b、然后等到发送缓存有足够多的数据（最大报文段长度），或者等到收端确认的ACK时再发送数据。

c、重复b的过程

（2）、收端进程由于消耗数据很慢，所以可能会有这么一种情况，收端会发送其窗口大小为1的信息，然后有是1字节的传输

解决办法（2种）

a、Clark方法：在接收缓存的一半变空，或者有足够空间放最大报文长度之前，宣告接收窗口大小为0

b、推迟确认：在对收到的报文段确认之前等待到足够的接收缓存，或者等待到一个时间段（现在一般定义500ms）

慢启动

虽然流量控制可以避免发送方过载接收方，但是却无法避免过载网络，这是因为接收窗口「rwnd」只反映了服务器个体的情况，却无法反映网络整体的情况。

为了避免过载网络的问题，慢启动引入了拥塞窗口「cwnd」的概念，用来表示发送方在得到接收方确认前，最大允许传输的未经确认的数据。「cwnd」同「rwnd」相比不同的是：它只是发送方的一个内部参数，无需通知给接收方，其初始值往往比较小，然后随着数据包被接收方确认，窗口成倍扩大，有点类似于拳击比赛，开始时不了解敌情，往往是次拳试探，慢慢心里有底了，开始逐渐加大重拳进攻的力度。

Slow Start

在慢启动的过程中，随着「cwnd」的增加，可能会出现网络过载，其外在表现就是丢包，一旦出现此类问题，「cwnd」的大小会迅速衰减，以便网络能够缓过来。

说明：网络中实际传输的未经确认的数据大小取决于「rwnd」和「cwnd」中的小值。

T C P的 流 量 控 制 由 连 接 的 每 一 端 通 过 声 明 的 窗 口 大 小 来 提 供 。 窗 口 大 小 为 字 节 数 ， 起 始于确认序号字段指明的值，这个值是接收端正期望接收的字节。窗口大小是一个16 bit字段，因 而 窗 口 大 小 最 大 为6 5 5 3 5字节。在2 4 . 4节 我 们 将 看 到 新 的 窗 口 刻 度 选 项 ， 它 允 许 这 个 值 按 比例变化以提供更大的窗口。检验和覆盖了整个的T C P报文段:T C P首部和T C P数 据 。 这 是 一 个 强 制 性 的 字 段 ， 一 定 是由发端计算和存储，并由收端进行验证。T C P检验和的计算和U D P检 验 和 的 计 算 相 似 ， 使 用一 个 伪 首 部 。只有当U R G标志置1时 紧 急 指 针 才 有 效 。 紧 急 指 针 是 一 个 正 的 偏 移 量 ， 和 序 号 字 段 中 的 值相加表示紧急数据最后一个字节的序号。T C P的 紧 急 方 式 是 发 送 端 向 另 一 端 发 送 紧 急 数 据 的一种方式。

拥塞避免