IP,TCP和HTTP

OSI.png

​ 可以参考OSI模型定义了七层结构。
​ 着重探讨特殊的混合模式：基于IP的TCP，以及基于TCP实现的HTTP。这个是我们每天app的基本网络配置。
​ 其实在互联网上传递数据的方式并不只 HTTP 一种。HTTP 之所以被广泛使用的原因是其非常稳定、易用，即便是防火墙一般也是允许 HTTP 协议穿透的

IP Header

一个IP数据包通常包含header（报头信息）和payload（有效载荷）。
payload中的内容既是要传输的真正的信息，而header承载的是与传输数据有关的元数据（metadata）。
Header长度为20字节
header信息中最关键的是源和目标IP地址。

Fragmentation（数据分片）

由于底部链路层对所传输的数据帧有最大长度的限制，所以有时候我们需要对数据进行分片。假如数据超出了数据的长度而数据源没有启用对传输数据包进行分片，就会收到ICMP(Internet Control Message Protocol，Internet报文控制协议) 的数据帧超长报告信息。
在IPv6中，如果数据包超限制，路由会直接丢弃数据包并且向发送源回传ICMP6的数据帧超长报告信息。源和目标两端会基于这个特性来路径MTU（maximum transfer unit）发现,以此寻找两端之间最大传输单元所在的路由。找到MTU路由后，仅当上层数据包的最小pauload（负载）确实超过了MTU，IPv6才会进行分片传输。对于IPv6下的TCP，这bu不会造成什么问题。

TCP

TCP是基于IP层的协议，但是TCP是可靠的，有序的，有错误检查机制的基于字节流传输的协议。

TCP建立的是双向的连接，通信双方可以同时进行数据的传输。

TCP用不同的端口号来区分应用。（IP地址和端口号）

TCP Segments（TCP报文段）

​ 主机之间传输的数据流一般先会被分块，再转化成 TCP 的报文段，最终会生成 IP 数据包中的 payload 载荷数据。
​ 每个 TCP 报文段都有 header 信息和对应的载荷 payload。payload 信息就是待传输的数据块。TCP 报文段的 header 信息中主要包含的是源和目标端口号，至于说源和目标的 IP 地址信息则已经包含在 IP header 信息中了。

TCP连接

三次握手

数据传输

​ TCP 将流量控制和其他一系列复杂机制结合起来进行拥塞控 制。需要处理以下问题：针对丢失的报文采用重发机制，同时还需要动态的调整发送报文的频率

终止连接

最终连接会终止（或结束）。连接的每一端都会发送 FIN 标识给另一端来声明结束传输，接着另一端会对收到 FIN 进行确认。当连接两端均发送完各自 FIN 和做出相应的确认后，连接将会彻底关闭。

HTTPS

Transport Layer Security (安全传输层协议，TLS) 是一种基于 TCP 的加密协议。它支持两件事：
传输的两端可以互相验证对方的身份，以及加密所传输的数据

基于 TLS 的 HTTP 请求就是 HTTPS。

基于HTTPS的请求，在网络安全方面有显著的提升。但是请求会比较耗时。

综合结论

有效的适应连接
TCP连接容易在两个时点出现问题：初始设置，以及通过传输的最后一部分报文。

建立连接

连接设置可能会比较耗时。TCP建立连接的过程中需要进行三次握手。这个过程中本身没有太多的数据需要传递。但是，对于移动网络来说，从手机端向服务器端发送一个数据包普遍需要 250ms，也就是四分之一秒。推及到三次握手，也就是说在还没有传送任何数据之前，光建立连接就要花费 750ms。
HTTPS 的情况更夸张，由于 HTTPS 是基于 TLS 的 HTTP，而 HTTP 又基于 TCP。TCP 连接就要执行三次握手，然后到了 TLS 层还会再握手三次。估算一下，建立一个 HTTPS 连接的耗时至少是创建一个 HTTP 连接的两倍。如果 RTT 时间是 500ms（假设单程 250ms），HTTPS 建立连接累计总耗时将达1.5秒。

长连接和管线化

HTTP有两种策略来解决这些问题。最简单的是HTTP持久连接，也被称为长连接。具体就是，每当HTTP完成一组请求相应之后，还会复用相同的TCP连接。而HTTPS会复用同样的TLS连接：

client sends HTTP request 1 ->
<- server sends HTTP response 1
client sends HTTP request 2 ->
<- server sends HTTP response 2
client sends HTTP request 3 ->
<- server sends HTTP response 3
close connection

第二步就利用了 HTTP 管线 (pipelining) 处理，即允许客户端利用同样的连接并行发送多个请求，也就是说无需等待上一个请求的响应完成可以发下一个请求。这表示能同时处理请求和响应，请求处理的顺序采用先进先出原则，响应结果会按照请求发出的顺序依次返还给客户端。
稍微简化一下，看起来会是这样：

open connection
client sends HTTP request 1 ->
client sends HTTP request 2 ->
client sends HTTP request 3 ->
client sends HTTP request 4 ->
<- server sends HTTP response 1
<- server sends HTTP response 2
<- server sends HTTP response 3

                       <- server sends HTTP response 4

close connection

注意：服务器发出的相应是实时的，不会等到接受全部请求才处理。
可以利用这个特点来提升 TCP 的效率。只需要在建立连接初始阶段执行握手，而后一直复用同样的连接，这样 TCP 就可以最大限度的利用带宽。此种情况下，拥塞控制也会随之提升。因为快速重发机制无法处理的最末四个报文丢失情况只会发生在使用本连接的最后一个请求－响应中，而不是像之前那样每一个请求－响应都需要建立自己的连接，每个连接中都可能出现最后四个报文丢失的问题。

本文来源：链接