本篇为 《计算机网络自顶向下方法》 的读书笔记，主要介绍：网络分层模型、HTTP 协议、非持续连接和持续连接、报文格式、cookie 与 session、 FTP 协议、HTTPS 协议、TCP 协议、流量控制、UDP 协议 等。

网络协议分层模型

ISO 提出的计算机网络 OSI（Open System Interconnection Reference Model） 七层模型：

TCP / IP 分层模型：

分层体系的优点：HTTP 协议不用担心数据丢失，也 不关注 TCP 从网络的数据丢失和乱序故障中恢复的细节。那是 TCP 以及协议栈较低层协议的工作。

应用层

现代网络应用有两种主流体系结构：客户 - 服务器体系结构 或 对等（P2P）体系结构。网络应用通过 socket 软件接口向网络发送报文 message 和从网络接收报文来实现在 不同端系统上的进程间的通信。

应用层协议定义了：

  • 换的报文类型，例如请求报文和响应报文 。
  • 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的 。
  • 字段的语义，即这些字段中包含的信息的含义 。
  • 一个进程何时以及如何发送报文，对报文进行响应的规则。

HTTP 协议

Web 的应用层协议是超文本传输协议 (HyperText Transfer Protocol , HTTP) ，客户端和服务器端通过交换 HTTP 报文进行会话，HTTP 定义了这些报文的结构以及客户和服务器进行报文交换的方式。

HTTP 定义了 Web 客户向 Web 服务器请求 Web 页面的方式，以及服务器向客户传送 Web 页面的方式。HTTP 使用 TCP 作为它的支撑运输协议，TCP 为 HTTP 提供可靠数据传输服务。

HTTP 2 相对于 HTTP 1.1 的区别有：

  • 头信息压缩，有效地减少带宽
  • 推送功能，服务器端可以主动向客户端发起一些数据传输，可以并行推送资源文件，显著地提升了整体的传输效率和性能。

非持续连接和持续连接

非持续性连接（non-persistent connection）是每个请求 / 响应对是经一个单独的 TCP 连接发送，而持续连接（persistent connection）是所有的请求及其响应经相同的 TCP 连接发送。HTTP 在其默认方式下使用持续连接，HTTP 客户和服务器也能配置成使用非持续连接 。

在非持续连接状态下， HTTP 服务器进程会在每次向客户发送响应后通知 TCP 断开连接，导致向客户返回一个 Web 页面需要产生多个 TCP 连接。非持续连接的 缺点：

  • 每个 TCP 连接都需要两个往返时间（Round-Trip Time，RTT），一个 RTT 用于创建 TCP，另一个 RTT 用于请求和接受一个对象，如此每个对象都要经受两倍 RTT 的交付时延。

  • 对于每个连接，在客户和服务器中都要分配 TCP 的缓冲区和保持 TCP 变量，这给 Web 服务器带来了严重的负担，因为一 台 Web 服务器可能同时服务于数以百计不同的客户的请求 。

而在采用持续连接的情况下，服务器在发送响应后 保持该 TCP 连接 打开，使一个完整的 Web 页面请求甚至对同个客户可以用单个持续的 TCP 连接进行传输。如果一个连接经过一段时间间隔仍未被使用，HTTP 服务器就关闭该连接。

在 HTTP / 1.0 中默认使用非持续连接；而从 HTTP / 1.1 起默认使用持续连接，以保持连接特性，会在请求 / 响应头中加入：（它不会永久保持连接，有一个保持时间）

Connection：keep-alive

HTTP 报文格式

以访问 www.baidu.com 为例，HTTP 请求报文格式（每行由一个回车和换行符结束）：

GET 和 POST 请求的主要区别如下：

  • GET 方法会将请求参数放在 URL 中（见 Web：浅析 URL），POST 方法会将请求参数放在请求体之中，以表单形式传输。
  • GET 请求提交的数据最多只有 1024 bytes，而 POST 请求没有这个大小限制。
  • GET 请求会将敏感信息暴露在 URL 中，容易造成密码泄露。

服务器返回的响应头为（返回的 HTML 文件会放在响应的实体体 entity body 中）：

因为 HTTP 服务器并不保存关于客户的任何信息，所以我们说 HTTP 是一个 无状态协议（stateless protocol），这简化了服务器的设计，并且允许工程师去开发可以同时处理数以千计的 TCP 连接的高性能 Web 服务器。通过 Cookie 允许了站点对用户进行跟踪，识别用户并将内容与用户身份联系起来。

首次访问某网站时，返回的响应头中会包含 set-cookie 首部行，用户端系统的游览器会对接收到的 cookie 进行保存管理；当之后再访问该网站时，游览器会从 cookie 文件中获取对应的识别码，并放到 HTTP 请求头首部行中发送出去。

在这种方式下，该网站服务器可以跟踪用户在其站点的活动，虽然不知道具体的用户信息，但用户在什么时间访问了哪些页面都可以被记录，网站通过 cookie 来记住用户名、提供购物车服务、推荐产品、保留用户地址支付方式信息等。

与 cookie 相对的，session 是在服务器端记录信息确定用户身份的机制。客户端浏览器再次访问时只需要从该 session 中查找该客户的状态就可以了。每个用户访问服务器都会建立一个session，那服务器是怎么标识用户的唯一身份呢？事实上，用户与服务器建立连接的同时，服务器会自动为其分配一个 sessionId。客户端通过 cookie 将 sessionId 带到服务器。当一个用户提交了表单时，浏览器会将用户的 sessionId 自动附加在 HTTP 头信息中（这是浏览器的自动功能，用户不会察觉到），当服务器处理完这个表单后，将结果返回给 sessionId。

推荐阅读：cookie、session和application都是些什么神？

FTP：文件传输协议

HTTP 和 FTP 都是运行在 TCP 上，然而 FTP 使用了两个并行的 TCP 连接来传输文件，一个是控制连接（control connection），一个是数据连接（data connection）。

控制连接用于发送用户的标识和口令，发送改变远程目录的命令，它会贯穿整个用户会话期间（持续连接），而数据连接会在每次用户需要传输文件时被打开，传送后被关闭（即数据连接是非持续的）。 此外 HTTP 是无状态的，而 FTP 服务器会在整个会话旗舰保留用户的状态。

HTTPS

HTTP 协议以明文方式发送内容，不提供任何方式的数据加密，如果攻击者截取了 Web 浏览器和网站服务器之间的传输报文，就可以直接读懂其中的信息，因此，HTTP 协议不适合传输一些敏感信息，比如：信用卡号、密码等支付信息。

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

HTTP 与 HTTPS 区别

  • HTTP 明文传输，数据都是未加密的，安全性较差，HTTPS（SSL+HTTP） 数据传输过程是加密的，安全性较好。
  • 使用 HTTPS 协议需要到 CA（Certificate Authority，数字证书认证机构） 申请证书，一般免费证书较少，因而 需要一定费用。证书颁发机构如：Symantec、Comodo、GoDaddy 和 GlobalSign 等。
  • HTTP 页面 响应速度比 HTTPS 快，主要是因为 HTTP 使用 TCP 三次握手建立连接，客户端和服务器需要交换 3 个包，而 HTTPS除了 TCP 的三个包，还要加上 SSL 握手需要的 9 个包，所以一共是 12 个包。
  • HTTP 和 HTTPS 使用的是完全不同的连接方式，用的端口也不一样，前者是 80，后者是 443。
  • HTTPS 其实就是建构在 SSL / TLS 之上的 HTTP 协议，所以，要比较 HTTPS 比 HTTP 要更耗费服务器资源。

HTTPS 工作原理

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。

  1. 客户使用 HTTPS 的 URL 访问 Web 服务器，要求与 Web 服务器建立 SSL 连接。
  2. Web 服务器收到客户端请求后，会将网站的证书信息（证书中包含 公钥）传送一份给客户端。
  3. 客户端的浏览器与 Web 服务器开始协商 SSL 连接的安全等级，也就是信息加密的等级。
  4. 客户端的浏览器根据双方同意的安全等级，建立会话密钥，然后利用网站的公钥将会话密钥加密，并传送给网站。
  5. Web 服务器利用自己的 私钥解密出会话密钥。
  6. Web 服务器利用会话密钥加密与客户端之间的通信。
  7. 服务端返回时会先对响应体用 Hash 函数，生成摘要，然后使用私钥对摘要加密，生成数字签名。
  8. 为了防止网站被篡改或劫持，服务端可以去证书中心 Certificate Authority 为公钥做认证，证书中心用自己的私钥和一些相关信息生成数字证书。如此，服务端在返回时需同时附上数字签名和数字证书，客户端用证书中心的公钥去解密数字证书就可以获取网站真实的公钥了，再去解密数字签名就能拿到真实的内容摘要了。

运输层

TCP 报文段结构

下图显示了 TCP 报文段的结构，其首部包括源端口号和目的端口号，它被用于多路复用/分解来自或送到上层应用的数据。

  • 检验和字段（checksum field）
  • 32 Bits 的序号字段和 32 Bits 的确认号字段，用来实现可靠数据传输服务
  • 16 Bits 的接收窗口字段，用于流量控制
  • 6 Bits 的 标志字段，ACK Bit 用于指示确认字段中的值是有效的，即该报文段包括一个对已被成功接收报文段的确认 。 RST、SYN 和 FIN 比特用于连接建立和拆除，

可靠数据传输

TCP 在 lP 不可靠的尽力而为服务之上创建了 一种 可靠数据传输服务，确保一个进程从其接收缓存中读出的数据流是无损坏、无间隔、非冗余和按序的数据流；即该字节流与连接的另 一方端系统发送出的字节流是完全相同 。 （丢包重传、超时重传）

通过 三次握手 来建立一条 TCP 连接：

  1. 第一次握手：客户端通过向服务器发送一段含有同步标志（SYN = 1）的数据，向服务器请求建立连接，通过这个数据段，客户端告诉服务器，我想要和你通信，你可以使用哪个序列号作为起始数据段来回应我。
  2. 第二次握手：服务器收到客户端的请求后，为该 TCP 连接分配 TCP 缓存和变量，用一个带有确认应答（ACK）和同步序列号（SYN = 1）标志位的数据段响应客户端，也告诉服务器两件事情：1.我已经收到你的请求，你可以传输数据了。2.你要用那个数据段来回应我。
  3. 第三次握手：客户端收到这个数据段之后，也要给该连接分配缓存和变量，再发送一个确认应答，确认已经收到服务器的数据段。告诉服务器，我已经收到回复，现在可以传输实际数据了。

通过 四次挥手 来断开一条 TCP 连接：

  1. 第一次，当客户端完成数据传输后，将控制位 FIN 置 1，提出停止 TCP 连接的请求。
  2. 第二次，服务器收到 FIN 后对其作出确认响应，确认这一方向上的 TCP 连接将关闭，将 ACK 置1。
  3. 第三次，由服务器再 提出反方向的关闭请求，将 FIN 置 1。
  4. 第四次，客户端对服务器的请求进行确认，将 ACK 置 1，双方关闭结束，释放用于该连接的所有资源。
  5. 为什么需要四次挥手：客户端在数据传输结束后发出连续释放的通知，待对方确认后进入半关闭状态；服务器在传输完最后一段数据后，也发出释放通知，待对方确认后再完全关闭 TCP 连接。

流量控制

每一侧主机都为 TCP 连接设置了接收缓存，接收到的数据会被放入接收缓存，相关的应用进程会从该缓存中读取数据。如果某应用程序 读取数据时相对缓慢，而发送方发送得太多 、 太快，发送的数据就会很容易地使该连接的接收缓存溢出 。

TCP 为其应用程序提供了流量控制服务，以 消除发送方使接收方缓存溢出的可能性。流量控制因此是个速度匹配服务。TCP 是全双工通信，在连接两端的发送方都各自维护一个 接收窗口，给发送方一个指示 —— 该接收方还有多少可用的缓存空间，以实现流量控制。

与之相对的，TCP 发送方也可能因为 IP 网络的拥塞而被遏制（通过拥塞窗口），称为 拥塞控制。

UDP 协议

使用 UDP 时，因为发送方和接收方的运输层实体之间没有握手，UDP 也被称为是无连接的。 UDP 相比 TCP 有以下几个特点：

  • 没有流量控制和拥塞控制，更适合实时应用。
  • 无需握手，不会引入建立连接的时延。
  • UDP 不需要维护连接状态，一般能支持更多的活跃客户。
  • 相比 TCP 20 个字节的首部开销，UDP 仅有 8 字节。