计算机网络知识回顾
本文内容基于《计算机网络》第6版，谢希仁著。
0. 计算机网络体系结构
1. 物理层
2. 数据链路层
3. 网络层
4. 传输层
4.1 UDP
4.1.1 UDP的特点
4.2 TCP
4.2.1 TCP的特点
4.2.2 TCP三次握手
4.2.3 TCP四次挥手
5. 应用层
5.1 DNS
5.1.1 为什么机器在处理IP数据报时要使用IP地址而不是域名？
5.1.2 DNS域名的解析过程？
5.2 FTP
5.2.1 TFTP
5.3 TELNET
5.4 HTTP
5.4.1 输入URL后的整个过程
5.4.2 HTTP的特点
5.4.3 HTTP的报文结构
5.4.4 HTTP版本特性
5.5 SMTP、POP3和IMAP
5.5.1 SMTP基础
5.5.2 SMTP的缺点
5.5.3 POP3
5.5.4 IMAP
5.5.5 区别SMTP、POP3和IMAP
5.5.6 基于万维网的电子邮件
5.6 HTTPS
5.6.1 加密危机
5.6.2 信任危机
5.6.3 HTTPS的大致流程
0. 计算机网络体系结构
1. 物理层
2. 数据链路层
3. 网络层
4. 传输层
4.1 UDP
4.1.1 UDP的特点
- UDP是无连接的；
- UDP尽最大努力交付，即不保证可靠交付；
- UDP是面向报文的，即UDP对应用层交下来的报文在添加首部后就向下交付IP层；
- UDP没有拥塞控制，即网络出现拥塞不会使得发送速率降低；
- UDP支持一对一、一对多、多对一和多对多的交互通信；
- UDP的首部开销小，只有8个字节。
4.2 TCP
4.2.1 TCP的特点
- TCP是面向连接的；
- TCP提供可靠交付，即无差错、不丢失、不重复并且按序到达；
- TCP是面向字节流的，即TCP把应用层交下来的报文看成是一连串的无结构的字节流，把一定量的字节加上首部后就形成了报文段然后向下交付IP层；
- TCP有拥塞控制，TCP根据对方给出的窗口大小和当前网络拥塞的程度来决定一个报文段应该包含多少字节，并且TCP提供全双工通信；
- TCP只能是一对一的通信；
- TCP首部开销比UDP大，有20个字节。
4.2.2 TCP三次握手
- 服务器处于LISTEN状态，等待客户端的连接请求；
- 客户端向服务器发出连接请求报文段，其中同步位SYN=1，初始序号seq=x，客户端进入SYN_SENT状态；
- 服务器接收到连接请求报文段之后，向客户端发送连接确认报文段，其中同步位SYN=1，确认位ACK=1，确认号ack=x+1，初始序号seq=y，服务器进入SYN_RCVD状态；
- 客户端接收到连接确认报文段之后，向服务器发送确认报文段，其中确认位ACK=1，确认号ack=y+1，序号seq=x+1，客户端进入ESTABLISHED状态；
- 服务器接收到确认报文段之后，进入ESTABLISHED状态；
- TCP连接建立。
【注】
- 当同步位SYN=1且确认位ACK=0时，表示这是一个连接请求报文段；当同步位SYN=1且确认位ACK=1时，表示这是一个连接确认报文段。
- 确认号的意思是“如果你发给我的序号是x，我发给你的确认号就是x+1，表示到序号x我已经收到了，我希望你下次发给我的序号是x+1”。
- 确认报文段，即ACK报文段，如果没有携带数据，是不消耗序号的。
为什么需要三次握手？
- 信息对等
客户端和服务器都需要确认4类信息：自己的发报能力、自己的收报能力、对方的发报能力、对方的收报能力，才能建立连接。
第一次握手后，服务器能确认自己的收报能力和对方的发报能力；
第二次握手后，客户端能确认自己的发报能力、自己的收报能力、对方的发报能力和对方的收报能力；
第三次握手后，服务器能确认自己的发报能力和对方的收报能力。
- 防止超时
报文的生存时间往往都会超过TCP请求超时时间。
如果两次握手就可以创建连接，传输数据并释放连接后，第一个超时的连接请求才到达服务器的话，服务器会以为是客户端创建新连接的请求，然后确认同意创建连接，但是这时候客户端的状态不是SYN_SENT，就直接丢弃服务器的确认数据，导致服务器单方面创建连接完毕。
如果是三次握手，则服务器收到连接请求后，同样会向客户端确认同意创建连接，但因为客户端不是SYN_SENT状态，所以会直接丢弃，服务器由于长时间没有收到确认信息，最终超时导致创建失败，因而不会出现脏连接。
4.2.3 TCP四次挥手
- 客户端和服务器都处于ESTABLISHED状态，双方都可以释放连接；
- 客户端向服务器发送连接释放报文段，其中终止位FIN=1，序号seq=u，客户端进入FIN_WAIT_1状态；
- 服务器接收到连接释放报文段之后，向客户端发送确认报文段，其中确认位ACK=1，确认号ack=u+1，序号seq=v，服务器进入CLOSE_WAIT状态；
- 客户端接收到确认报文段之后，进入FIN_WAIT_2状态，等待服务器发送连接释放报文段；
注意，此时客户端不再向服务器发送数据了，但是服务器可能还需要向客户端发送数据。
- 如果服务器不需要向客户端发送数据了，就向客户端发送连接释放报文段，其中终止位FIN=1，确认位ACK=1，确认号ack=u+1，序号seq=w（不是v+1是因为上面又发送了一些数据），服务器进入LAST_ACK状态；
- 客户端接收到连接释放报文段之后，向服务器发送确认报文段，其中确认位ACK=1，确认号ack=w+1，序号seq=u+1，客户端进入TIME_WAIT状态；
注意，此时TCP连接还没有释放掉，客户端要等待2MSL才自动进入CLOSED状态，这是因为：第一，客户端上一步向服务器发送的确认报文段可能会丢失；第二，让这一次TCP连接中的报文段都从网络中消失，不会影响下一次TCP连接。
- 服务器接收到确认报文段之后，进入CLOSED状态；
- TCP连接释放。
5. 应用层
5.1 DNS
5.1.1 为什么机器在处理IP数据报时要使用IP地址而不是域名？
这是因为IP地址的长度是固定的32位，IPv6是128位，而域名的长度并不是固定的，机器处理起来比较困难。
5.1.2 DNS域名的解析过程？
首先要了解域名：
然后要了解DNS的域名服务器：
DNS域名解析过程（某个主机想要知道另外一个主机的IP地址）：
本地域名服务器采取迭代查询：
- 某个主机向本地域名服务器进行递归查询（UDP减少开销）；
- 本地域名服务器向根域名服务器进行迭代查询；
- 根域名服务器判断顶级域名，然后告诉本地域名服务器，去查询对应的顶级域名服务器；
- 本地域名服务器向顶级域名服务器进行迭代查询；
- 顶级域名服务器判断二级域名，然后告诉本地域名服务器，去查询对应的权限域名服务器；
- 本地域名服务器向权限域名服务器进行迭代查询；
- 权限域名服务器告诉本地域名服务器所查询的主机的IP地址；
- 本地域名服务器告诉主机所查询的主机的IP地址。
本地域名服务器采取递归查询：
在域名服务器中存在缓存，所以如果某个阶段在缓存中查到了，就不需要向下继续查询了。
5.2 FTP
文件传送协议FTP只提供文件传送的一些基本的服务，它使用TCP可靠的运输服务。FTP的主要功能是减少或消除在不同操作系统下处理文件的不兼容性。
FTP使用客户服务器方式，一个FTP服务器进程可同时为多个客户进程提供服务。FTP的服务器进程由两大部分组成：一个主进程，负责接受新的请求；另外有若干个从属进程，负责处理单个请求。
当客户进程向服务器进程发出建立连接请求时，要寻找连接服务器进程的熟知端口21，同时还要告诉服务器进程自己的另一个端口号码，用于建立数据传送连接。接着，服务器进程用自己传送数据的熟知端口20与客户进程所提供的端口号码建立数据传送连接。
5.2.1 TFTP
简单文件传送协议TFTP是一个很小且易于实现的文件传送协议，虽然也是用客户服务器方式，但它使用UDP数据报。
端口号码69。
5.3 TELNET
TELNET是一个简单的远程终端协议。用户用TELNET就可在其所在地通过TCP连接注册（即登陆）到远地的另一个主机上（使用主机名或IP地址）。
TELNET也使用客户服务器方式，在本地系统运行客户进程，在远地主机则运行服务器进程。
5.4 HTTP
5.4.1 输入URL后的整个过程
- 浏览器向DNS请求解析该主机（域名）的IP地址；
- ARP解析IP地址成MAC地址；
- 浏览器与服务器建立TCP连接；
- 浏览器发出GET请求，获取数据；
- 服务器给出响应，把数据发送到浏览器；
- 释放TCP连接；
- 浏览器解析数据，并展示。
5.4.2 HTTP的特点
- HTTP是面向事务的；
HTTP协议定义了浏览器怎样向万维网服务器请求万维网文档，以及服务器怎样把文档传送给浏览器。从层次的角度看，HTTP是面向事务的应用层协议，它是万维网上能够可靠地交换文件的重要基础。
- HTTP本身是无连接的；
HTTP使用了面向链接的TCP作为传输层协议，保证了数据的可靠传输。HTTP不必考虑数据在传输过程中被丢弃后又怎样被重传。但是，HTTP协议本身是无连接的，这就是说虽然HTTP使用了TCP连接，但通信的双方在交换HTTP报文之前不需要先建立HTTP连接。
- HTTP是无状态的；
HTTP协议是无状态的。也就是说，同一个客户第二次访问同一个服务器上的页面时，服务器的响应与第一次被访问时相同，因为服务器并不记得曾经访问过的这个客户，也不记得为该客户服务过多少次。HTTP的无状态特性简化了服务器的设计，使服务器更容易支持大量并发的HTTP请求。
5.4.3 HTTP的报文结构
HTTP有两类报文：
- 请求报文：从客户向服务器发送请求报文；
- 响应报文：从服务器到客户的回答。
HTTP请求报文和响应报文都是由三个部分组成，这两种报文格式的区别就是开始行不同：
- 开始行：用于区分是请求报文还是响应报文，请求报文中的开始行叫做请求行，响应报文中的开始行叫做状态行；
- 首部行：用来说明浏览器、服务器或报文主体的一些信息；
- 实体主体：在请求报文中一般都不用这个字段，而在响应报文中也可能没有这个字段。
HTTP请求报文中的请求行包括三个内容：方法、URL以及版本，如：GET http://baidu.com HTTP/1.1，其中方法如下表所示：
| 方法 | 意义 |
| OPTION | 请求一些选项的信息 |
| GET | 请求读取由URL所标志的信息 |
| HEAD | 请求读取由URL所标志的信息的首部 |
| POST | 给服务器添加信息 |
| PUT | 在指明的URL下存储一个文档 |
| DELETE | 删除指明的URL所标志的资源 |
| TRACE | 用来进行环回测试的请求报文 |
| CONNECT | 用于代理服务器 |
HTTP响应报文中的状态行包括三个内容：HTTP的版本、状态码以及解释状态码的短语，如：HTTP/1.1 202 Accepted，其中状态码如下所示：
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的 PUT 请求时可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
5.4.4 HTTP版本特性
- HTTP 1.0
在HTTP 1.0中，一次请求响应就需要建立一次连接，用完后连接即关闭。每个新的请求又要重新建立一个新的连接。
- HTTP 1.1
在HTTP 1.1中，使用Pipeling优化了HTTP 1.0中的问题，即通常所说的Keep-Alive模式。当连接建立后，多个请求通过串行化的单线程方式进行处理，排在后面的请求必须等待前面的请求处理完才能获得执行机会。一旦有请求处理耗时较长，后续的请求都只能被迫阻塞。
- HTTP 2.0
二进制协议：HTTP 1.x的解析是基于文本的，HTTP 2的解析是基于二进制的，新协议称为二进制分帧层，它重新设计了编码机制，更加适用于服务器间信息传输。
多路复用：多个请求在同一个连接上并行执行，每个请求都有一个ID，这样在一个连接上可以发送多个请求，并且它们在传输过程中是混杂在一起的，接收方可以根据请求的ID将请求再归属到不同的服务端请求里。
请求优先级：资源传输中优先加载重要资源。
报头压缩：HTTP 2协议拥有配套的HPACK，目的是尽可能减少客户端请求与服务器响应之间的头部信息重复所导致的性能开销。报头压缩的方式是要求客户端和服务器都维护之前看见的头部字段的列表，减少网络传输的内容。
服务端推送：HTTP 1.x只能是客户端主动拉取资源，HTTP 2支持从服务端推送资源至客户端。当服务器在处理请求的同时，可以将一些静态资源如CSS或JavaScript推送到客户端。
流控制：流控制管理数据的传输，使数据发送者不会让数据接收者不堪重负。流控制允许接收者停止或减少发送的数据量。例如一个视频网站，当观众观看一个视频时，服务器向客户端发送数据，如果视频暂停，客户端会通知服务器停止或者减少发送视频数据，以避免客户端过载。
5.5 SMTP、POP3和IMAP
5.5.1 SMTP基础
简单邮件传送协议（SMTP）规定了在两个相互通信的SMTP进程之间应如何交换信息，使用客户-服务器方式。
发送方和接收方的邮件服务器之间的SMTP通信的三个阶段：
- 连接建立；
发件人的邮件送到发送方邮件服务器的邮件缓存后，SMTP客户就每隔一定时间对邮件缓存扫描一次。如发现有邮件，就使用端口号25与接收方邮件服务器的SMTP服务器建立TCP连接。
- 邮件传送；
- 连接释放。
5.5.2 SMTP的缺点
- SMTP不能传送可执行文件或其他的二进制对象，而是传送ASCII码；
- SMTP限于传送7位的ASCII码；
- SMTP服务器会拒绝超过一定长度的邮件；
- 某些SMTP的实现并没有完全按照SMTP的因特网标准。
5.5.3 POP3
邮局协议第3个版本（POP3）是一个非常简单、功能有限的邮件读取协议，也是用客户-服务器的工作方式。
POP3的一个特点就是只要用户从POP服务器读取了邮件，POP服务器就把该邮件删除。
5.5.4 IMAP
网际报文存取协议（IMAP）相对POP3来说比较复杂，也是用客户-服务器的工作方式。
在使用IMAP时，在用户的PC上运行IMAP客户程序，然后与接收方的邮件服务器上的IMAP服务器程序建立TCP连接。用户在自己的PC上就可以操纵邮件服务器的邮箱，就像在本地操纵一样，因此IMAP是一个联机协议。
在用户未发出删除邮件的命令之前，IMAP服务器邮箱中的邮件一直保存着。
5.5.5 区别SMTP、POP3和IMAP
发件人的用户代理向发送方邮件服务器发送邮件、发送放邮件服务器向接收方邮件服务器发送邮件是使用的SMTP协议。
用户代理从接收方邮件服务器上读取邮件使用的POP3或IMAP。
5.5.6 基于万维网的电子邮件
5.6 HTTPS
安全套接字层（SSL）协议工作于传输层与应用层之间，为应用提供数据的加密传输，HTTPS的全称是HTTP over SSL，简单的理解就是在之前的HTTP传输上增加了SSL协议的加密能力。
传输层安全协议（TLS）和SSL的区别：TSL可以理解为SSL 3.0版本的升级，即SSL 3.1。
5.6.1 加密危机
可以通过对称加密算法如DES，对数据进行加密，即一个网站与用户之间可以使用相同的密钥对传输内容进行加解密，但是密钥几乎没有什么保密性可言，如果与每一个用户之间都约定一个独立的密钥，如何把密钥传输给对方是一个安全难题。
也可以通过非对称加密算法如RSA，对数据进行加密，即可以把公钥发给对方（不存在安全问题，因为是私钥解密），一方发送消息时，使用另一方的公钥进行加密生成密文，收到密文的一方再用自己的私钥进行解密。非对称加密有个明显的缺点是加解密耗时长，只适合对少量数据进行处理。
结合对称加密和非对称加密的解决方案，如果把对称加密的密钥用非对称加密算法加密后再传输不就完美解决问题了么，这就是HTTPS用来建立安全的SSL连接的方案。
5.6.2 信任危机
上述过程可以描述为这样：
- A告诉B，使用RSA算法对密钥进行加密；
- A和B各自生成一对公钥、私钥，互相发送公钥；
- A使用B的公钥加密，然后发送给B；
- B使用自己的私钥解密，然后用A的公钥加密，并发送给A；
- A使用自己的私钥解密。
重点关注第2个步骤，A和B互相将自己的公钥发送给对方的过程中，可以存在C对A或B的消息进行了拦截，并且C自己生成了一对公钥和私钥来和另一个人通信。
为了解决信任危机，就需要一个具有公信力的组织来证明身份，CA就是颁发HTTPS证书的组织，在基于HTTPS进行连接时，就需要数字证书。
5.6.3 HTTPS的大致流程
- 浏览器向服务器发送请求，请求中包括浏览器支持的协议（SSL版本），并附带一个随机数；
- 服务器收到请求后，选择某种非对称加密算法（如RSA），把数字证书签名公钥、身份信息发送给浏览器，同时也附带一个随机数；
- 浏览器收到后，验证证书的真实性，用服务器的公钥发送握手信息给服务器；
- 服务器用自己的私钥解密后，使用之前的随机数计算出一个对称加密的密钥，以此作为加密信息并发送；
- 后续所有的信息发送都是以对称加密方式进行的。