关于网络基础概念的学习笔记

---

1. OSI 模型

层	功能	协议数据单元
应用层	网络进程到应用程序。包括资源共享，远程文件访问你。	data
表示层	网络服务和应用程序之间的数据转换。(加密解密，格式编码、压缩等)	data
会话层	管理通信会话。（以两节点间多次往返传输的形式交换数据）	data
传输层	提供数据段在网络间的可靠传输。包括分段、确认和复用	segment
网络层	构建和管理多节点网络。包括寻址、路由和流量控制	packet
数据链路层	负责网络寻址、错误侦测和改错。（LLC、MAC）	frame
物理层	在物理介质上传输和接收原始比特流	bit

• 第7层 应用层（Application Layer）

应用层最接近最终用户，这意味着 OSI应用层 和用户通过应用程序直接地交互。该层与实现“通信组件”的应用程序交互。应用层功能通常包括识别通信伙伴，确定资源可用性和同步通信。
例如：HTTP，HTTPS，FTP，SSH，SMTP，POP3等协议。

• 第6层 表示层（Presentation Layer）

把数据转换为能与接收者的系统格式兼容并适合传输的格式。

• 第5层 会话层（Session Layer）

负责在数据传输中设置和维护电脑网络中两台电脑之间的通信连接。

• 第4层 传输层（Transport Layer）

把传输表头（TH）加至数据以形成数据包。传输表头包含了所使用的协议等发送信息。例如：传输控制协议义（TCP）等。

• 第3层 网络层（Network Layer）

决定数据的路径选择和转寄，将网络表头（NH）加至数据包，以形成分组。网络表头包含了网络数据。例如：互联网协议（IP）等。

• 第2层 数据链接层（Data Link Layer）

负责网络寻址、错误侦测和改错。当表头和表尾被加至数据包时，会形成了帧。数据链表头（DLH）是包含了物理地址和错误侦测及改错的方法。数据链表尾（DLT）是一串指示数据包末端的字符串。例如以太网、无线局域网（Wi-Fi）和通用分组无线服务（GPRS）等。
分为两种子层：logic link control sublayer & media access control sublayer

• 第1层 物理层（Physical Layer）

在局部局域网上传送帧，它负责管理电脑通信设备和网络媒体之间的互通。包括了针脚、电压、线缆规范、集线器、中继器、网卡、主机适配器等

2. IP 网络协议

  在 IP网络协议下，通信机器被称作主机（host），IP 网络下的主机都配有自己的地址，被称为 IP 地址。协议明确了host之间数据包的传输方式。
  IP 用于计算机之间的通信。IP 是无连接的通信协议。它不会占用两个正在通信的计算机之间的通信线路。这样，IP 就降低了对网络线路的需求。每条线可以同时满足许多不同的计算机之间的通信需要。通过IP，消息（或者其他数据）被分割为小的独立的包，并通过因特网在计算机之间传送。IP 负责将每个”数据包“路由至它的目的地。
数据包：

数据包为二进制数据，其中包含了发送源主机和目标主机的信息（当然包含主机IP地址）。IP网路负责源主机与目标主机之间数据包的传输，但在传输过程中，数据可能会丢失，也有可能重复传输导致目标主机收到多个相同的数据包。IP数据包的传输过程中，经过每一个主机节点都会读取数据包中目标主机地址信息，从而计算传输路径。

  IPv4（Internet Protocol version 4 网际协议版本 4）

• IPv4 地址长度：32位
• 常见表示方式：十进制
• 例：192.168.1.146

  IPv6

作为新一代数据包标准，IPv6拥有更大的地址空间，这有利于数据包在传输过程中的网络寻址。由于有更多的地址可以分配，有关网络地址转换（NAT）等问题也迎刃而解。

• IPv6 地址长度：128位
• 常见表示方式：八位十六进制数以冒号（:）分隔
• 例：2001:0db8:85a3:0042:1000:8a2e:0370:7334

  IP数据包通常包含 header（报头）和 payload（有效载荷）两部分。
  payload 中的内容是发送源主机真正要发送给目标主机的信息。而 header中承载的是与传输数据有关的元数据（当然，也包含之前提到的源主机与目标主机的 IP 地址）。

2.1 IP Header

2.1.1 IPv4 Header

IPv4 的 header（报头）信息如下：

IPv4 报头格式

2.1.1.1 各字段功能

1. Version（版本号）：长度 4bit，用于标识某数据包所采用的IP协议版本号，一般值为0100（IPv4），0110（IPv6）。

版本号	0	1~3	4	5	6	7	8	9	10~14	15	16
版本	保留	未分配	Internet 协议版本4（IPv4）	ST数据报（Datagram）	简单Internet协议（SIP）	IPv6	TP/IX	P Internet 协议（PIP）	使用更大地址的TCP和UDP（TUBA）	未分配	保留

2. Header Length（IP 报头长度）：长度 4bit，用于描述报头的长度。因为IP包头中有可变长的可选部分。该部分占用 4 个 bit，长度单位为 4 个 Byte。（即，本区域值 = IP 报头长度（单位： Byte）/ 长度单位（4 Byte））。因此，一个 IP报头的最大长度为 "1111"，即，15*4 Byte = 60 Byte。IP 报头最小长度为20 Byte。

Header Length	0101	0110	0111	...	1100	1101	1110	1111
Header Length所代表的实际的IP报头长度（单位： Byte）	20	24	28	...	48	52	56	60

3. Type of Service（服务类型），长度 8bit，按位被如下定义：PPP DTRC0
   PPP：前3位，定义包的优先级，取值越大数据越重要

• 000 普通 (Routine)
• 001 优先的 (Priority)
• 010 立即发送 (Immediate)
• 011 闪电式 (Flash)
• 100 超越闪电式的 (Flash Override)
• 101 CRI/TIC/ECP(。。。)
• 110 网间控制 (Internetwork Control)
• 111 网络控制 (Network Control)

   DTRCO：后5位

• D 时延: 0:普通 1:延迟尽量小
• T 吞吐量: 0:普通 1:流量尽量大
• R 可靠性: 0:普通 1:可靠性尽量大
• M 传输成本: 0:普通 1:成本尽量小
• 0 最后一位被保留，恒定为0

4. Total Length（IP 数据包总长度）：长度 16bit，以字节为单位计算的IP包的长度 (包括头部和数据)，所以IP包最大长度65535 Byte。所以，数据包有效载荷的大小 = IP包总长度（Total Length）- IP报头长度（Header Length）。

5. Identifier（标识符）：长度16bit。该字段和Flags和Fragment Offest字段联合使用，对较大的上层数据包进行分段（fragment）操作。路由器将一个包拆分后，所有拆分开的小包被标记相同的值，以便目的端设备能够区分哪个包属于被拆分开的包的一部分。

6. Flags（标记）：长度3bit。

• 该字段第一位不使用。
• 第二位是DF（Don’t Fragment）位，DF位设为1时表明路由器不能对该上层数据包分段。如果一个上层数据包无法在不分段的情况下进行转发，则路由器会丢弃该上层数据包并返回一个错误信息。
• 第三位是MF（More Fragments）位，当路由器对一个上层数据包分段，则路由器会在除了最后一个分段的IP包的报头中将MF位设为1。

7. Fragment Offset（数据分片）：长度 13bit，用于对包含分段的上层数据包的IP包赋予序号。
     由于底层数据链路层对所传输数据帧有最大长度的限制（最大传输单元，MTU），具体表现为，如果数据包尺寸超过了所要经过的数据链路的最大传输限制，路由就会对数据包进行分片。当分片数据包到达目标主机后，可以根据分片信息进行数据重组。当然，数据发送源有权决定路由是否启用对传输数据包进行分片，假如所传输的数据超过了输送限制，又禁止了路由分片，发送源会收到 ICMP(Internet Control Message Protocol，Internet报文控制协议) 的数据帧超长报告信息。

8. TTL（Time to live，生命周期）：长度 8bit，设计之初是以秒（s）为单位的，但实际以跳数为单位，建议的缺省值为64。
     当IP包进行传送时，先会对该字段赋予某个特定的值。当IP包经过每一个沿途的路由器的时候，每个沿途的路由器会将IP包的TTL值减少1。如果TTL减少为0，则该IP包会被丢弃。这个字段可以防止由于路由环路而导致IP包在网络中不停被转发。

9. Protocol（协议）：长度8bit。标识了上层（payload）使用的协议。
   以下是比较常用的协议号：

协议号	1	2	6	17	88	89	...
协议名	ICMP	IGMP	TCP	UDP	IGRP	OSPF	...

10. Header Checksum（头部校验）：长度16位，用来做IP头部的正确性检测，但不包含数据部分。 因为每个路由器要改变TTL的值，所以路由器会为每个通过的数据包重新计算这个值（RFC1141讨论了一些简化计算的策略）。

11. Source Addresses（发送源主机地址）

12. Destination Addresses（目标地址）
    与发送源主机地址，长度都是32bit。标识了这个IP包的起源和目标地址。要注意除非使用NAT，否则整个传输的过程中，这两个地址不会改变。

  !!! IP数据包报头信息中，最关键的是发送源主机和目标主机的 “IP 地址”。

13. 可选项（Options）：这是一个可变长的字段。该字段属于可选项，主要用于测试，由起源设备根据需要改写。可选项目包含以下内容：

• 松散源路由（Loose source routing）：给出一连串路由器接口的IP地址。IP包必须沿着这些IP地址传送，但是允许在相继的两个IP地址之间跳过多个路由器。
• 严格源路由（Strict source routing）：给出一连串路由器接口的IP地址。IP包必须沿着这些IP地址传送，如果下一条不在IP地址表中则表示发生错误。
• 路由记录（Record route）：当IP包离开每个路由器的时候记录路由器的出站接口的IP地址。
• 时间戳（Timestamps）：当IP包离开每个路由器的时候记录时间。
• 填充（Padding）：因为IP报头长度（Header Length）部分的单位为32bit，所以IP报头的长度必须为32bit的整数倍。因此，在可选项后面，IP协议会填充若干个0，以达到32bit的整数倍。

2.1.2 IPv6 Header

IPv6 的 header（报头）信息如下：

IPv6 报头格式

  可以看出，IPv6 的 header 信息相比 IPv4 简化了许多。除了源和目标地址这种必备信息外，IPv6 提供专门的 next header 区域来指明紧接 header 的数据是什么。也就是说，IPv6 允许在数据包中将 header 链接起来。每一个被链接的 IPv6 header 都会有一个 next header 字段，直到到达实际的 payload 数据。
  比如说，当 next header 的值为 6 (TCP 的协议号) 时，数据包的其他信息就是 TCP 协议要传输的数据。

2.1.2.1 各字段功能

1. Version（版本）：4bit，值为6（二进制值为0110）表示IPv6报文。

2. Traffic Class（流量类别）：8bit，这相当于IPv4协议中的ToS（Type of Service）字段。但是，考虑到ToS字段这些年的发展，现在都用来做区分服务等级（Differentiated Class of Service，DiffServ）了。所以，即使这个字段和旧的ToS字段有些相似，它们的名字要比所传送的值更能确切地反映目前的用处。

3. Flow Label（流标签）：20bit，IPv6中新增。流标签可用来标记特定流的报文，以便在网络层区分不同的报文。转发路径上的路由器可以根据流标签来区分流并进行处理。由于流标签在IPv6报文头中携带，转发路由器可以不必根据报文内容来识别不同的流，目的节点也同样可以根据流标签识别流，同时由于流标签在报文头中，因此使用IPSec后仍然可以根据流标签进行QoS处理。

4. Payload Length（有效载荷长度）：16bit，以字节为单位的IPv6载荷长度，也就是IPv6报文基本头以后部分的长度（包括所有扩展头部分）。IPv4的总长度字段是16位的，但IPv6的有效载荷长度字段却是20位，这就意味着该字段能够指定更长的有效载荷（1 048 575字节，相对IPv4中只有65 535字节）。

5. Next Header（下一报头）：8bit，用来标识当前头（基本头或扩展头）后下一个头的类型。此域内定义的类型与IPv4中的协议域值相同。Pv6定义的扩展头由基本头或扩展头中的扩展头域链接成一条链，每一个被链接的 IPv6 header 都会有一个 next header 字段，直到到达实际的 payload 数据。。这一机制下处理扩展头更高效，转发路由器只处理必须处理的选项头，提高了转发效率。比如说，当 next header 的值为 6 (TCP 的协议号) 时，数据包的其他信息就是 TCP 协议要传输的数据。

6. Hop Limit（跳数限制）：8bit，和IPv4中的TTL字段类似。每个转发此报文的节点把此域减1，如果此域值减到0则丢弃。注意：IPv4中的TTL设计之初是以秒（s）为单位的，但实际使用时跟IPv6中的Hop Limit一样，是以跳数为单位。

7. Source Address（源地址）：128bit，报文的源地址。

8. Destination Address（目的地址）：128bit，报文的目的地址

3. TCP 协议

  TCP（Transmission Control Protocol，传输控制协议）。TCP 层位于 IP 层之上，是最受欢迎的因特网通讯协议之一，人们通常用 TCP/IP 来泛指整个因特网协议族。

  两台主机基于IP协议进行数据包传输，目标主机（即接收方）收到的数据很可能是乱序的、重复的，甚至丢包。但 基于”IP协议“之上的”TCP 传输协议“是比”IP协议“更可靠、有序 、有错误检查机制的基于字节流传输的协议。在这一整套的机制保护下，TCP协议 几乎可以保证目标主机所接收到的数据是有序且与发送方所发送的数据是一致的。

  TCP 用于应用程序之间的通信。当应用程序希望通过 TCP 与另一个应用程序通信时，它会发送一个通信请求。这个请求必须被送到一个确切的地址。在双方“握手”之后，TCP 将在两个应用程序之间建立一个**全双工 **(full-duplex) 的通信。这个全双工的通信将占用两个计算机之间的通信线路，直到它被一方或双方关闭为止。同一 host 主机上可以有多个应用程序同时使用 TCP，TCP 依赖不同的端口来区分应用。即，通过TCP协议 的通信双方都会拥有自己IP地址 和 端口号（同一主机IP地址相同），借此就可以唯一标识一个连接。HTTP 是典型的 TCP 的应用。用户浏览器（应用 1）与 web 服务器（应用 2）建立连接后，浏览器可以通过连接发送服务请求，web 服务器可以通过同样的连接对请求做出响应。

  同一个 host 主机上可以有多个应用同时使用 TCP 协议。TCP 用不同的端口来区分应用。作为连接的两端，发送源和接收目标分别拥有自己的 IP 地址和端口号。凭借这样一对 IP 地址和端口号，就可以唯一标识一个连接。

  TCP 在 IPv4 和 IPv6 上是无差别运行的。所以，如果 IPv4 的 Protocol 或 IPv6 的 Next Hearder的协议号被设置成 6，表示执行 TCP 协议。

3.1 TCP Segments (TCP 报文段)

主机之间传输的数据流一般先会被分块，再转化成 TCP 的报文段，最终会生成 IP 数据包中的 payload 载荷数据。

每个 TCP 报文段都有 header 信息和对应的载荷 payload。payload 信息就是待传输的数据块。TCP 报文段的 header 信息中主要包含的是源和目标端口号，至于说源和目标的 IP 地址信息则已经包含在 IP header 信息中了。

TCP 的报文段 header 信息中还有报文序列号、确认号等其他一些用于管理连接的信息。

所谓序列号信息，其实就是为每个报文段分配的唯一编号。第一个报文段的序列号是随机的，比如：1721092979，其后的每一个报文段的序列号都以此号为基础依次加 1，1721092980，1721092981 等等。至于确认号，是目标端反馈给源的确认信息，通知源目前已经接到哪些报文段了。由于 TCP 是双向的，所以数据和确认信息发送也都是双向的。

3.2 TCP 连接

TCP 连接全过程的状态变化：

TCP状态图

1. 连接的建立

  TCP连接是建立在两个主机间的。所以每个连接过程都会存在两个角色，一端（如 web 服务器）监听连接，而另一端（例如应用程序）主动连接正在监听连接的另一端（web 服务器）。服务器（server）种监听行为成为passive open（被动打开），而客户机（client）主动连接服务器（server）行为称作active（主动打开）。

TCP 连接过程中的三次握手：

• client 向 server 发送一个 SYN 包和一个随机序列号 A
• server 收到后回复 client 一个SYN-ACK 包和一个确认号（用于确认收到 SYN）A+1，同时向 client 发送一个随机序列号 B
• client 接收到 server 所发送的数据后，会发送一个 ACK 包以及确认号（用于确认收到 SYN-ACK）B+1，和序列号A+1

  SYN是Synchronize Sequence Number（同步序列号）的缩写。两端在传递数据时，所传递的每个 TCP 报文段都有一个序列号。就是利用这种机制，TCP 可以确保分块传输的数据包最终都以正确的个数和顺序抵达目标端。在正式传输开始之前，源和目标端需要同步确认第一个报文的序列号。

  ACK 是 Acknowledgment （确认）的缩写。当某一端接到了报文包后，通过回传已报文序列号来确认接收到报文这件事。

2. 数据传输
     一旦双方建立了连接，就可以发送数据了。发送端所发送的每个报文段都有一个序列号，这个序列号与当前已发送字节的总数有关。接收端会针对已接收的数据包向源端发送确认报文，确认信息同样是由报文 header 所携带的 ACK。

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

  流量控制的原则是发送方发送数据的速度不能比接收方处理数据的速度快。接收方，也就是所谓的 接收窗口 (receive window) 会告知发送方自身接收窗口数据缓冲区的大小。

  拥塞控制，目的是计算出当前网络中数据传输的最佳速率。所谓最佳速率就是要达到一种微妙的平衡。一方面，是希望速度越快越好，另一方面，速度过快意味着数据传输多，这样处理性能会大打折扣甚至导致崩溃。而这种超负荷崩溃是分组交换网络的固有特点。当负载过大，数据包之间会产生拥塞，直接导致丢包率急速上升。除却计算最佳速率，还需要充分考虑对流量的影响。发送方要时刻关注来自接收方的确认信息。要做到这点并不简单，有的时候还需要一定的妥协。要知道底部 IP 协议数据包是无序传输的，数据包会丢失也会重复。发送方需要评估 RTT （往返传输时间），然后基于 RTT 去确定是否收到了接收方的确认信息。重发数据包也有很大代价，除了连接延迟问题，网络的负载也会发生明显的波动。导致 TCP 需要不停的去适应当前网络情况。

RTT由三部分组成

• 链路的传播时间（propagation delay）
• 末端系统的处理时间
• 路由器缓存中的排队和处理时间（queuing delay）

  前两者对一个 TCP 连接来说比较固定。而 queuing delay 会随着整个网络的阻塞程度的变化而变化。

  更重要的是，TCP 连接本身是易变的。除了数据传输，连接的两端还会不时的发送一些提醒和确认信息以便可以适当的调整状态来维持连接。基于这种一直在相互协调中的连接关系，TCP 连接往往会是短暂而低效的。在建立连接的初期，TCP 协议算法还不能完全了解当前网络状况。而在连接将要结束的时候，反馈给发送方的信息又可能不充分，这样就很难对连接状况做出实时的合理的评估。

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

4. TCP/IP 协议

  TCP/IP 是 Transmission Control Protocol / Internet Protocol （传输控制协议/网际协议）的简称，是用于已连接因特网 (Internet) 的计算机的通信协议。它定义了电子设备（比如计算机）如何连入因特网，以及数据如何在它们之间传输的标准。

在 TCP/IP 中包含一系列用于处理数据通信的协议：

• TCP (传输控制协议) - 应用程序之间通信
• UDP (用户数据包协议) - 应用程序之间的简单通信（和 TCP 很相似，但是更简单，同时可靠性低于 TCP）
• IP (网际协议) - 计算机之间的通信
• ICMP (因特网消息控制协议) - 针对错误和状态
• DHCP (动态主机配置协议) - 针对动态寻址

TCP/IP 协同关系

• TCP 负责应用程序与网络软件之间的通信
• IP 负责计算机之间的通信
• TCP 负责将数据分割并装入 IP 数据包，在它们到达时重组
• IP 负责将数据包发送给接收者

5. HTTP 协议

  HTTP 是 Hypertext Transfer Protocol（超文本传输协议）的缩写。

5.1 请求与响应

  HTTP 协议采取“请求与响应机制”。此处的请求与响应是指应用程序（客户端与服务器）之间的连接依赖于客户端的主动打开，即当一应用程序（客户端）向服务器发送一条请求，服务器做出与其对应的响应。在此过程之前、之后客户端与服务器之间不保持连接。也就是说，HTTP协议下的连接是“无状态”连接。

以下是用Chrome Devtools抓取到的一次简单 HTTP Request Header 信息：

POST /MecMis/user/manager/getClassList HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Content-Length: 3
Pragma: no-cache
Cache-Control: no-cache
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://localhost:8080
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.90 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://localhost:8080/MecMis/user/manager.html?id=201401
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.8
Cookie: JSESSIONID=716BAFB8111A6933CBC61F4165E67C4F

第一行是请求行，包含三部分信息：

• HTTP 方法 : POST
  其他的 HTTP 方法类型（GET HEAD OPTIONS PUT DELETE TRACE CONNECT，具体作用不在此分析）
• 资源信息 : /MecMis/user/manager/getClassList
• HTTP 的版本 : HTTP/1.1
  接下来十余行是 HTTP header 信息。跟着是一行空行。例子中的请求没有 body 信息。

header 的作用是向服务器传递一些数据之外的辅助信息，本例中Host: localhost:8080是告知服务器本次请求的服务器名称是什么。这样可以让同一个服务器处理针对多个域名的请求。

简单分析以下 HTTP 请求header字段：

• Accept : application/json, text/javascript, */*; q=0.01
  服务器可能具备返回多种媒体类型的能力，Accept 表示 chrome （客户端）希望接收的媒体格式类型。text/javascript 是互联网媒体类型(Internet media types)，也被称为 MIME 类型或者是内容类型 (Content-types)。q=0.8 表示 chrome 对给定媒体类型的优先级要求。
• Accept-Encoding : gzip, deflate, br
  chrome 告诉服务器可以对响应 body 做压缩处理。如果 header 信息中没有设置压缩标识，那么服务器就必须返回没有压缩过的信息。压缩可以大大减少数据的传输量，在文本信息 (比如 HTML) 中尤为明显。
• Accept-Language : zh-CN,zh;q=0.8
  代表 chrome 希望接收的自然语言清单。这会要求服务器尽可能的根据清单要求去匹配相应的语言。
• Cookie : JSESSIONID=716BAFB8111A6933CBC61F4165E67C4F
  这两行信息表明 chrome 曾经经将请求相关身份信息写入 cookie 中（Browser 缓存机制的一种）。此处JSESSIONID是 Apache 服务器的用户身份标识，服务器会据此在服务器检索与该用户相关的请求数据然后响应。

以下是一次与上述请求对应的 HTTP Response Header 信息：

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: application/json;charset=UTF-8
Transfer-Encoding: chunked
Date: Tue, 08 Aug 2017 07:30:31 GMT

第一行是状态行，包括 HTTP 版本，状态码 (200) 和状态信息（OK）。
服务器同时还告知请求方服务器的版本信息Apache-Coyote/1.1，响应 body 的类型是 application/json；字符集 charset=UTF-8。以及服务器做出响应的时间。

6. HTTPS 协议

  HTTPS，超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种通过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网站服务器的身份认证，保护交换数据的隐私与完整性。

  虽然 HTTPS 带来了更加安全的网络环境，但由于 HTTPS 本身就是基于 TLS 的 HTTP，而 HTTP 每次连接都要进行三次握手，而 TLS 连接的建立也需要握手三次，这样一来 ，一次 HTTPS 的连接连接耗时最低是 HTTP 的二倍。

---

  这只是一次文章搬移，最初只是自己写于 2017.08.13 的学习笔记，并没有发布的打算。现希望发布后，有纰漏、错误的地方大家多多提宝贵意见，一起学习交流。