计算机网络

HTTP协议发展历史 HTTP0.9 1991年发布。该版本极其简单，只有一个命令GET，不支持请求头 HTTP/1.0 1996年5月发布。引入请求头和响应头；新增请求方法，如head/post HTTP1.1 1997年1月发布。支持长连接；添加Content-Length字段；分块传输编码等 SPDY 2012年Google发布。HTTP2.0就是基于SPDY设计的，现在已经无人使用。添加多路复用（Multiplexing）；header压缩（DEFLATE算法）；服务端推送等 HTTP2.0 2015年发布。本文主要讲解内容，后文详细讨论。 HTTP3.0 2018年发布。尚未研究，不在本文讨论范围。 HTTP/2 的wiki介绍，可以看下定义和发展历史。RFC 7540 定义了 HTTP/2 的协议规范和细节, RFC 7541定义了头部压缩。如果有时间，最后就直接看RFC的文档。没有什么资料可以比官方文档写的更清楚。本文只是自已的归纳和整理。难免有些粗陋和错误，望评判指正。 一、HTTP2 解决什么问题 HTTP2的提出肯定是为了解决HTTP1.1已经存在的问题。所以HTTP1.1存在那些问题呢？ 1.1 TCP连接数限制 因为并发的原因一个TCP连接在同一时刻可能发送一个http请求。所以为了更快的响应前端请求，浏览器会建立多个tcp连接，但是第一tcp连接数量是有限制的。现在的浏览器针对同一域名一般最多只能创建6~8个请求；第二创建tcp连接需要三次握手，增加耗时、cpu资源、增加网络拥堵的可能性。所以，缺点明显。 1.2 线头阻塞 (Head Of Line Blocking) 问题 每个 TCP 连接同时只能处理一个请求 - 响应，浏览器按 FIFO 原则处理请求，如果上一个响应没返回，后续请求 - 响应都会受阻。为了解决此问题，出现了 管线化 - pipelining 技术，但是管线化存在诸多问题，比如第一个响应慢还是会阻塞后续响应、服务器为了按序返回相应需要缓存多个响应占用更多资源、浏览器中途断连重试服务器可能得重新处理多个请求、还有必须客户端 - 代理 - 服务器都支持管线化。 1.3 Header 内容多 每次请求 Header不会变化太多，没有相应的压缩传输优化方案。特别是想cookie这种比较长的字段 对于HTTP1.1存在的这些问题，是有一定的优化方案的，比如用对个域名，文件合并等。但是这些毕竟比较麻烦，甚至无聊。 二、基本概念 数据流: 已建立的连接内的双向字节流，可以承载一条或多条消息。 消息: 与逻辑请求或响应消息对应的完整的一系列帧。 帧: HTTP/2 通信的最小单位，每个帧都包含帧头，至少也会标识出当前帧所属的数据流。 这些概念的关系总结如下: 所有通信都在一个 TCP 连接上完成，此连接可以承载任意数量的双向数据流。 每个数据流都有一个唯一的标识符和可选的优先级信息，用于承载双向消息。 每条消息都是一条逻辑 HTTP 消息（例如请求或响应），包含一个或多个帧。 帧是最小的通信单位，承载着特定类型的数据，例如 HTTP 标头、消息负载等等。 来自不同数据流的帧可以交错发送，然后再根据每个帧头的数据流标识符重新组装。 三、HTTP2特性有那些 需要强调的是HTTP/2 是对之前 HTTP 标准的扩展，而非替代。 HTTP 的应用语义不变，提供的功能不变，HTTP 方法、状态代码、URI和标头字段等这些核心概念也不变。 我们已经知道http1....

本文借助wireshark抓包详细的讲解SSL/TLS协议。HTTPS是为了解决http报文明文传输过程中的安全问题。HTTPS是“HTTP over SSL”的缩写。所以要了解HTTPS就必须先了解SSL/TLS协议。 一、HTTP协议的风险 HTTP协议中所有消息都是明文传播，存在如下三大风险 窃听风险（eavesdropping）：第三方可以获知通信内容。 篡改风险（tampering）：第三方可以修改通信内容。 冒充风险（pretending）：第三方可以冒充他人身份参与通信。 为了解决这个三个风险，分别对应如下三个解决方案。 加密：所有信息都是加密传播，第三方无法窃听。 校验：具有校验机制，一旦被篡改，通信双方会立刻发现。 身份验证：配备身份证书，防止身份被冒充。 二、SSL/TLS 发展历史 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。 1996年，SSL 3.0版问世，得到大规模应用。 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。 2006: TLS 1.1. 作为 RFC 4346 发布。主要fix了CBC模式相关的如BEAST攻击等漏洞。 2008: TLS 1.2. 作为RFC 5246 发布 。增进安全性。目前(2015年)应该主要部署的版本。 2015之后: TLS 1.3，还在制订中，支持0-rtt，大幅增进安全性，砍掉了aead之外的加密方式。 由于SSL的2个版本都已经退出历史舞台了，所以本文后面只用TLS这个名字。 一般所说的SSL就是TLS。 三、报文解析(rfc5246) TLS建立连接的过程如下图，先有个大概的印象，后面我们再详细分析。整个需要四次握手。 SSL/TLS工作在应用层和传输层之间，在建立连接的之前需要先建立TCP连接（三次握手），如下图。 3.1 详细过程 （1）Client Hello 从截图中可以看出TLS协议分为两个部分记录协议（Record Layer）和握手协议（Handshake Protocal）。 3.1.1 记录协议（Record Layer） 记录协议根据rfc描述记录协议（Record Layer）有如下4种类型，即上图中Content Type可以取的值。 记录协议（Record Layer） 数据结构 对照着wireshark抓包为：Content Type：Handshake(22), Version: TLS 1.0(0x0301), Length: 512 3.1.2 握手协议（Handshake Protocal） 握手协议（Handshake Protocal）有如下10种类型。 握手协议（Handshake Protocal）数据结构 对照着wireshark抓包为：Handshake Type: Client Hello, Length: 508, Version : TLS 1....

Abstract 本文借助wireshark抓包详细的讲解常用的网络协议。涉及的主要协议包括但不限于http协议、tcp协议、ip协议。为了表述的准确性，严重的参考了参考了谢希仁的《计算机网络》这本教程。 一、http请求抓包 通过如下命令请求一次百度的首页。 curl -v -i www.baidu.com 通过wireshark抓包如下： 其中 红色框：tcp三次握手 蓝色框：http请求与应答 绿色框：tcp四次挥手 本文会以上文的数据包来展开分析 在正式介绍之前，我们现在一张图，请求是如何一步一步封装的。以http请求为例 在数据链路层中有一个MTU的东西，表示上层payload最大的大小（单位byte） 有了这个东西就意味着如果上层的报文太大，必须要分割。在ip协议里叫分片；在tcp协议里叫分段，同时会涉及到tcp建立连接时（三次握手中的前两次握手），客户端和服务端会协商tcp header中MSS（最大数据报文段长度）字段。具体的我们后面会说道。 二、IP协议(RFC 791) IP数据报的格式如下图二 Ip数据报分为首部和数据部分两个部分。其中IP首部又分为固定首部+可变部分，固定部分长度固定为20个字节。 wireshark抓包如下： 2.1 IP header 固定部分 版本（4位）：IP协议的版本，目前的IP协议版本号为4，下一代IP协议版本号为6。 首部长度（4位）：IP报头的长度，注意单位为4个字节。固定部分的长度（20字节）和可变部分的长度之和。共占4位。最大为1111，即10进制的15，代表IP报头的最大长度可以为15*4=60字节，除去固定部分的长度20字节，可变部分的长度最大为40字节。 区分服务（8位）: 用来获得更好的服务，现在基本不用，可以忽略 总长度（16位）：IP报文的总长度。报头的长度和数据部分的长度之和。所以一个IP报文的的最大长度为65535个字节。受MTU限制，最大只能为1500字节 标识（16位）：唯一的标识主机发送的每一分数据报。通常每发送一个报文，它的值加一。当IP报文长度超过传输网络的MTU（最大传输单元）时必须分片，这个标识字段的值被复制到所有数据分片的标识字段中，使得这些分片在达到最终目的地时可以依照标识字段的内容重新组成原先的数据。 标志（3位）：共3位。R、DF、MF三位。目前只有后两位有效，DF位：为1表示不分片，为0表示分片。MF：为1表示“更多的片”，为0表示这是最后一片。 片位移（13位）：单位为8字节，指当前分片在原数据报（分片前的数据报）中相对于用户数据字段的偏移量，即在原数据报中的相对位置。（需要再乘以8） 生存时间（8位）：TTL（Time to Live）。该字段表明当前报文还能生存多久，现在指跳数。每经过一个网关，TTL的值自动减1，当生存时间为0时，报文将被认为目的主机不可到达而丢弃。TTL 字段是由发送端初始设置一个 8 bit字段.推荐的初始值由分配数字 RFC 指定，当前值为 64。发送 ICMP 回显应答时经常把 TTL 设为最大值 255。 协议（8位）：指出IP报文携带的数据使用的是那种协议，以便目的主机的IP层能知道要将数据报上交到哪个进程（不同的协议有专门不同的进程处理）。和端口号类似，此处采用协议号，TCP的协议号为6，UDP的协议号为17。ICMP的协议号为1，IGMP的协议号为2. 首部校验和（16位）：用于检验IP报文头部(不包含数据部分)在传播的过程中是否出错，检查IP报头的完整性。 源IP地址（32位）：源ip地址 目的IP地址（32位）：目标ip地址 2.2 IP header 不固定部分 就因为ip header存在不固定部分，所以在固定部分才需要字段首部长度。ip header中不固定部分主要是用来增加ip数据报的功能的（1-40字节）。但是该部分很少使用，所以IPv6中没有该部分。所以可以忽略这部分的内容。 2.3 关于IP数据报分片 前面有提到过，在数据链路层有MTU限制即IP数据报的最大报文长度为1500字节，那么当ip数据长度超过1500时候，就需要分片。举例如下： 假设一个数据报总长度为3820字节，其中数据部分为3800字节（使用固定首都20字节，无可变部分）。显然3820超过MTU，需要分片。假设分片长度不超1420字节，出去20字节首都，那每个分片数据部分最长为1400。所以需要将数据部分分为三个数据报片（1400、1400、1000）。那么分片后，如何重新组装回一个完整的IP数据报呢？就需要上面提到的标识和片位移两个字段。分成3个数据报片的标识字段是一样的。再加上片位移字段就能计算出该分片在原数据报中的位置。上面三个分片的片位移分别为（0/8=0; 1400/8=175; 2800/8=350）。注意片位移单位为8字节 三、TCP协议（RFC 793） TCP协议是比较复杂的，要是搞明白TCP协议，就需要回答三个问题。（1）TCP如何保证可靠性传输；（2）TCP如何做流量控制；（3）TCP如何做拥塞控制。我们先从简单的TCP报文段格式开始介绍。 TCP报文段的格式如下图三 3....