概述

网络体系结构

1. 五层协议

应用层：为特定应用程序提供数据传输服务 （HTTP、DNS等协议运行在应用层）

传输层：为进程提供通用数据传输服务，接收来自应用层的数据报文，并与对方传输层建立点对点的数据传输链路。运输层包括两种协议

1. TCP：提供面向连接，可靠的数据传输服务
2. UDP：用户数据报协议，无连接，尽力而为

网络层：为主机提供数据传输服务。把数据层传递下来的报文段或用户数据报封装成分组

数据链路层：把网络层传下来的分组封装成帧为同一链路的主机提供数据传输服务。

物理层：主要考虑怎样在传输媒体传输数据比特流。物理层的作用是尽可能屏蔽传输媒体和通信手段的差异，使数据链路层感觉不到这些差异

1. OSI 七层协议

将五层协议中的应用层细分成了应用层、会话层、表示层

会话层：数据压缩、加密以及数据描述。使得应用不关心在各主机中数据内部格式不同的问题

会话层：建立及管理会话

1. TCP/IP

只有四层，相当于五层协议中数据链路层和物理层合并成了网络接口层

1. 数据在各层之间的传递过程

自顶向下

对于主机，应用进程生成报文，一层一层向下封装（数据报文段/用户数据报-> 分组->帧 ），通过物理层向外经过路由器转发发送到目标主机物理层，再通过一层层向上解封装到达目标端口进程

对于路由器，只有下面三层协议，因为路由器位于网络核心，不需要为进程提供服务，所以不需要传输层和应用层

应用层

动态主机配置协议

DHCP (Dynamic Host Configuration Protocol) 提供了即插即用的连网方式，使得用户不需要再手动配置 IP 地址、子网掩码、DNS服务器IP等信息

DHCP的工作流程如下：

1. 客户端发送一个 discover 报文，该报文的目的地址为 255.255.255.255:67，源地址为 0.0.0.0:68，通过 UDP 协议发送，经过交换机被广播到同一个子网的所有主机（如果 DHCP 服务器和主机不在同一个子网，就需要一个中继代理）
2. DHCP 收到 discover 报文后，发送一个包含源主机所需要信息的 offer 报文给源主机客户端。因为客户端可能会收到多个 DHCPoffer 报文，所以需要选择
3. 如果客户端选择了某个 DHCP 服务器，就发送一个 request 报文给这个 DHCP 服务器
4. DHCP 服务器发送一个 ack 报文给客户端，表示此时可以使用提供给他的信息

浏览器输入一个 url 发生的过程

1. DHCP 配置主机信息

假设主机最开始没有 IP 地址和其他的信息，就需要先通过 DHCP 来获取，获取方式见上面

在获取到 DHCP 的 offer 报文后，主机解封装得到信息，并配置 IP 地址、子网掩码、DNS 服务器IP，并在其 IP 转发表中安装默认网关

1. ARP 解析 MAC 地址

DHCP 过程只需要知道网关路由器的 IP 地址，为了获取网关路由器的 MAC，还需要使用 ARP 协议

• 主机生成一个包含目的地址为网关路由器 IP 地址的 ARP 查询报文，将该报文放到具有广播目的地址（255.255.255.255：255）的以太网帧中，并向交换机发送该以太网帧，交换机把这个帧转发给子网所有连接设备

• 网关路由器收到该帧后，向上解封装得到 ARP 报文，发现其中的 IP 地址和其接口的 IP 地址匹配。因此发送一个包含有它的 MAC 地址的 ARP 应答报文给源主机

1. DNS 解析域名

• 主机通过浏览器生成一个 TCP 套接字，套接字向 HTTP 服务器发送 HTTP 请求。为了生成该套接字，主机还需要知道域名所对应的 IP 地址

• 所以需要先进行 DNS 查询。主机先生成一个 DNS 查询报文，通过 53 号端口发送到 DNS 服务器
• 到达 DNS 服务器之后，DNS 服务器解封装 DNS 查询报文，根据域名在数据库中查询对应IP
• 找到 DNS 记录之后，发送 DNS 应答报文，通过 UDP 反向转发回源主机

1. HTTP 请求页面

• 拿到域名对应的 IP 之后，主机先和 HTTP 服务器进行三次握手建立连接

• 建立连接之后，浏览器生成 HTTP GET 报文，发送给服务器请求相应的资源

• 服务器从 TCP 套接字读取该报文，并相应生成 HTTP 响应报文，将 Web 页面内容放入报文主体中，传回给主机

• 浏览器收到 HTTP 响应报文后，抽取出 Web 页面内容，并通过内核渲染显示出页面

传输层

传输层向高层用户屏蔽了下面网络层的核心细节，使应用程序看起来好像是在两个传输层实体之间有一条端到端的逻辑通信信道

UDP 和 TCP

• UDP 用户数据报协议。是无连接的，提供尽力而为的交付服务。没有拥塞控制，面向报文（对于应用层传下来的报文既不合并也不拆分，只是添加 UDP 首部）。支持一对一，一对多，多对一和多对多的交互通信
• TCP 传输控制协议。是面向连接的，提供可靠交付服务。有流量控制，拥塞控制，全双工通信，面向字节流（把应用层传下来的数据看成是字节流，把字节流组装成符合规格的报文段再发送）。TCP 连接是点对点的

TCP 三次握手

为什么不是两次而是三次

这是为了防止失效的连接请求发送到服务器，让服务器错误打开连接浪费资源

客户端发送的连接请求如果滞留在网络中，客户端在等待一个超时重传时间后，就会重新发送一个连接请求，这时候如果滞留的连接请求到达了服务器，如果只有两次握手，那么服务器就会错误地打开两个连接。如果客户端超时之后直接关闭不请求连接了，那么服务器就相当于打开了一个无效连接，造成资源的浪费。如果有第三次握手，客户端就会忽略服务器之后发送的对滞留连接请求的确认。

TCP 四次挥手

为什么是四次挥手

TCP 握手和挥手的流程其实是一样的，但是因为在建立连接的时候双方没有数据的交换，所以第二次和第三次可以合在一起。对于关闭连接的时候，客户端主动发起 FIN 连接释放请求，此时说明客户端已经没有数据需要传输，服务器接收到这个 FIN 请求需要对它返回一个确认 ACK 报文，同时进入 CLOSE_WAIT 状态。但是这个时候服务器可能还有数据没有发送完，需要把这部分数据传输完，服务器才能执行第三次挥手发送 FIN 连接释放报文

TIME_WAIT

TCP 的 TIMEWAIT 发生在四次挥手的最后阶段。客户端在接收到服务器发送来的 FIN 结束链接信号之后会发送一个 ACK 来进行最后一次挥手结束连接。这时候距离客户端真正关闭连接还有一段时间，我们把这段时间叫做 TIME_WAIT。这段时间主要有两个意义：

1. 确保客户端发送的最后一个 ACK 报文能到达服务器。如果服务器没有收到客户端的确认报文，就会重新再发送一次结束连接请求。如果客户端立即关闭的话，就会收不到这个请求
2. 等待一段时间的目的是为了让此次连接产生的所有报文都在网络中消失，不管是被接收还是在网络核心中丢包。防止下次连接的时候不会收到旧的报文

TCP 可靠传输

TCP 使用超时重传来实现可靠传输：如果一个已经发送的报文段在超时时间内没有收到确认，那么就重传这个报文段。

一个报文段从发送再到接收到确认所经过的时间称为往返时间 RTT

超时时间 RTO 应该略大于 RTTs

TCP 滑动窗口

窗口是缓存的一部分，用来暂时存放字节流。发送方和接收方各有一个窗口，接收方通过 TCP 报文段的窗口字段告诉发送方自己的窗口大小，发送方根据这个值设置自己的窗口大小。

对于发送窗口，TCP 按序列号顺序发送。如果发送方左边的字节已经发送并且收到了确认，那么就将窗口向右移动至第一个发送但未被确认的地方。接收窗口的滑动类似，接收窗口左边的字节已经发送确认并且交付给应用层，那么窗口向右移动。

接收窗口只会对窗口内最后一个按序到达的字节进行确认。发送方得到这个字节的确认后，表示这个字节之前的所有字节流都已经被接收

TCP 流量控制

流量控制是为了控制发送方发送的速率，保证接收方能来得及接收

接收方滑动窗口大小通过确认报文发送给发送方，发送方以此控制自己的窗口大小。

TCP 拥塞控制

在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做网络拥塞。

不同于流量控制是为了调节接收端使其能够接收报文，拥塞控制主要是为了降低网络的拥塞程度

TCP 主要通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复

发送方维护一个叫做拥塞窗口cwnd的状态变量，其值随着网络拥塞的程度动态变化，其值为多少就表示能发送多少个数据报文段

1. 慢开始 假设开始时 cwnd 的值为1，发送方只能发送一个报文段；接收方接收到该报文段后给发送方返回一个确认报文，发送方接收到这个确认报文段后，将拥塞窗口的值翻倍为2…依次类推，每次正常接收到确认报文段后，就把 cwnd 翻倍，直到当前拥塞窗口 cwnd 的值等于慢开始门限值 ssthresh，此时进入拥塞避免阶段

2. 拥塞避免

每个传输轮次，拥塞窗口的值只能加1，直到发生超时重传，发送方判断此时可能出现拥塞，更改 cwnd 和 ssthresh（cwnd置1，ssthresh 更改为当前 cwnd 的一半），并重新开始慢开始算法

1. 快重传和快恢复

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。

在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

在这种情况下，只是丢失个别报文段，而不是网络拥塞。因此执行快恢复，令 ssthresh = cwnd / 2 ，cwnd = ssthresh，注意到此时直接进入拥塞避免。

慢开始和快恢复的快慢指的是 cwnd 的设定值，而不是 cwnd 的增长速率。慢开始 cwnd 设定为 1，而快恢复 cwnd 设定为 ssthresh。

HTTP

状态码

1XX 信息

2XX 成功

• 200 OK

  3XX 重定向

• 301 Moved Permanently 永久重定向
• 302 Found 临时重定向

  4XX 客户端错误

• 404 NOT FOUND 找不到资源
• 403 Forbidden 请求被拒绝
• 400 Bad Request 请求报文中存在语法错误

5XX 服务器错误

• 500 Internal Server Error ：服务器正在执行请求时发生错误。
• 503 Service Unavailable ：服务器暂时处于超负载或正在进行停机维护，现在无法处理请求

Cookie 和 Session

• Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，他会在浏览器之后向同一服务器再次发送请求时被带上，用于告知服务器两个请求是否来自同一浏览器。由于之后每次请求都会需要携带 Cookie 数据，所以需要带来额外的性能开销
• Session 将这个数据存储在服务器上，用户数据被保存为 Session-ID 的 key并通过响应报文的 Set-Cookie 首部字段返回客户端浏览器，之后对同一服务器发起请求时会带上这个 Cookie 值（也可以用 url 重写技术将其作为 url 的参数进行传递） ，服务器收到之后从数据库中提取出相应的用户信息，继续操作

HTTPS

HTTP 主要有以下安全性问题

• 使用明文进行通信
• 不验证通信方的身份，可能遭遇伪装
• 无法证明报文的完整性，报文有可能会被篡改

HTTPS 在 HTTP 的基础上加了一层 SSL 隧道，让 HTTP 先和 SSL 通信，再由 SSL 和 TCP 通信

通过使用 SSL ，HTTPS 有了加密，认证，完整性保护

HTTPS 加密

HTTPS 采用对称加密 + 非对称加密方式保证不受中间人攻击

1. 服务器拥有一个私钥 A’ 和一个公钥 A
2. 服务器先通过明文方式将公钥 A 传输给浏览器
3. 浏览器随机生成一个用于对称加密的密钥 X，通过公钥 A 加密之后传输给服务器
4. 服务器拿到之后通过私钥 A’ 解密得到 X
5. 此时只有服务器和浏览器拥有密钥 X，可以通过对称加密通信

HTTPS 数字证书

网站在使用 HTTPS 前，需要向 CA 机构申领一份数字证书，里面含有证书持有者信息，公钥信息等。服务器把证书传输给浏览器，浏览器从证书里面获取公钥就可以了。

GET 和 POST