计算机网络基础

网络分层

将网络节点所要完成的数据的发送或转发、打包或拆包，以及控制信息的加载或拆出等工作，分别由不同的硬件或软件模块来完成。

计算机网络体系结构分为3种：OSI体系结构、TCP/IP体系结构、五层体系结构。

• OSI体系结构：概念清楚并且理念完整，但复杂且不实用
• TCP/IP体系结构：包含了一系列构成互联网基础的网络协议，是Intenet的核心协议并且被广泛应用于局域网和广域网
• 五层体系结构：融合了OSI与TCP/IP的体系结构。

以下主要分析 五层协议

物理层

传输数据单位为比特(bite)，负责比特流在节点间的传输，即负责物理传输。例如光纤等

具体协议：无

数据链路层

控制网络层与物理层之间的通信，主要功能是如何在不可靠的物理线路上进行数据的可靠传递。

链路层使用的信道主要有两种类型：

• 点对点信道
• 广播信道

具体协议：逻辑链路控制 LLC、媒体介入控制 MAC

网络层

如何将数据从发送方到接收方。将数据报从一台主机移动到另一台主机。

具体协议：IP协议、因特网控制报文协议ICMP

传输层/运输层

为两台主机上的应用程序提供通用的数据传输服务，传输内容为应用层报文。

具体协议：传输控制协议 TCP、用户数据报协议 UDP

应用层

网络应用程序和网络协议储存的分层。网络应用程序接收到传输层的数据后，就需要进行解读。

具体协议：文件传输协议 FTP、超文本传输协议 HTTP、域名系统 DNS

TCP协议

Transmission Control Protocol——传输控制协议 主要用于传输层

特点

特点	具体描述
面向连接	使用TCP传输数据前，必须先建立TCP连接；传输完成后在释放连接
面向字节流	虽然应用程序和TCP的交互是一次一个数据块，但TCP只把数据看外一连串无结构的字节流。数据以流的形式传输
全双工通信	建立TCP连接后，通信双方都能发送数据
可靠	通过TCP传输的数据：不丢失、无差错、不重复，按序到达

优缺点

优点：数据传输可靠

缺点：效率低（因为连接过程比较复杂）

应用场景

• 传输文件：HTTP、HTTPS、FTP等协议
• 传输邮件：POP、SMTP等协议

报文段格式

报文段分为两部分：

TCP首部：全部功能体现于此，最小长度为20字节。

TCP数据：传输的数据

TCP首部字段	作用	备注
序号 Sequence Number(seq)	本报文段所发送数据的第一个字节序号	占4字节
确认号 Acknowledgment Number(ACK)	期望收到对方下一个报文段的第一个数据字节的序号	占4字节 若ACK为n，代表到序号n-1之前的数据都已正确收到
同步位 SYN	连接建立时用于同步序号	SYN = 1,ACK = 0，表示是连接请求报文段 SYN = 1,ACK = 1，表示连接请求响应报文段
终止控制位 FIN	释放连接	FIN = 1表示此报文段的发送方已发送数据完毕并要求释放连接

建立连接过程——三次握手

客户端主动打开连接，服务器被动打开连接，然后进入LISTEN(监听)状态，等待接收客户端的请求。

第一次握手——客户端发送连接请求报文段到服务端

设置SYN = 1，seq = x；然后客户端进入SYN-SENT(同步已发送)状态，等待服务端确认。

第二次握手——服务器收到客户端请求连接报文段，对报文段内容进行确认

设置ack = x+1、SYN = 1，seq为y一并加入报文段中，发送给客户端；然后服务端进入SYN_RCVD(同步已接收)状态。

第三次握手——客户端收到服务端确认连接报文段，然后向服务端发送连接确认报文段

客户端收到服务端发出的SYN+ACK报文段；然后设置ACK = y+1，在向服务端发出ACK报文段，确认连接。然后客户端和服务端都进入ESTABLISHED(TCP连接成功)状态。

完成上述TCP的三次握手过程后，TCP连接建立完成，即可传送应用层数据。

由于TCP是全双工通信，服务端和客户端在任何时候都可以互相发送数据。

如果三次握手期间，任何一次没有收到对方的回复，都需要进行重发。超时重发机制

为什么需要进行三次握手？

防止服务端因接受了早已失效的连接请求报文，从而一直等待客户端请求，最终导致死锁，形成资源浪费。

SYN洪范攻击：利用了TCP的三次握手机制。模拟多个客户端发起连接请求，然后不处理服务端返回请求，这样就会导致服务端持续挂起，大量请求时会快速耗尽服务器资源，导致死机。

服务端的TCP资源分配发生在第二次握手结束时；客户端的TCP资源分配发生在第三次握手结束时。

如何对这种攻击进行防范？

优化主机系统设置，如降低SYN timeout时间；设置cookie，如果短时间内连续收到同IP请求，则对该IP的请求进行抛弃。

释放连接过程——四次挥手

第一次挥手——客户端向服务端发送连接释放报文段

设置FIN = 1发送至服务端；客户端进入FIN_WAIT_1(终止等待1)状态，此时客户端没有数据在需要发送了。

第二次挥手——服务端收到连接释放报文段，再向客户端发送连接释放确认报文段

设置ACK = 1发送至客户端；服务端进入CLOSE_WAIT(关闭等待)状态，客户端收到连接释放确认请求后，会进入FIN_WAIT_2(终止等待2)状态，等待服务端的释放连接请求。

此时客户端 -> 服务端的连接已断开

第三次挥手——若服务端没有再发送数据，则发出释放连接的报文段

设置FIN = 1发送至客户端，请求关闭连接；服务端进入LAST_ACK(最后确认)状态。

第四次挥手——客户端收到服务端的连接释放报文段，再向服务端发出连接释放确认报文段

客户端收到服务端连接释放请求，再向服务端发送释放连接确认报文段，客户端进入TIME_WAIT(时间等待)状态。

服务端收到释放连接确认报文段后，服务端进入CLOSED(关闭)状态。

客户端等待2MSL后依然没有收到回复，客户端进入CLOSED(关闭)状态。

为什么TCP释放需要四次挥手？

为了保证通信双方都通知到对方释放并断开连接。释放连接后，相互都无法发送和接收消息。

为什么需要等待2MSL时间没有回复在关闭？

MSL：最长报文段寿命

1. 为了保证客户端发送的最后一个连接释放确认报文可以到达服务端，使得服务端可以释放连接
2. 防止早已失效的连接请求报文出现在本次连接中。在2MSL时间内，在本连接中产生的所有报文都会消失。

可靠性保证

主要分析的是如何保证TCP传输的可靠性。

无论发送方以多块的速度发送数据，接收方总来得及处理收到的数据。

核心思想

出错重传：出现差错时，让发送方重新传输数据

速度匹配：当接收方来不及接收收到的数据时，通知发送方降低发送数据的效率。

滑动窗口协议

是传输层进行流控的一种措施，接收方通过告知发送放自己的窗口大小，从而控制发送方的发送速度，达到防止发送方发送速度过快导致自己被淹没的目的。

滑动窗口分为以下两部分：

类型	定义	作用
发送窗口	任意时刻，发送方维持的一组连续的，允许发送帧的帧序号	对发送方进行流量控制
接收窗口	任意时刻，接收方维持的一组连续的，允许接收帧的帧序号	控制可以接收的数据帧以及不可接收的数据帧 接收方只有当收到的数据帧的序号落入接收窗口才允许收下该数据帧；否则，丢弃。

工作原理

对于TCP的发送方

每收到一个确认帧，发送窗口就向前滑动一个帧的距离。当发送窗口内没有可以发送的帧时(窗口内的帧全部为已发送但未收到确认的帧)，发送方停止发送，直到收到接收方发送的确认帧使发送窗口移动，然后发送窗口内还有可以发送的帧则继续发送。

发送缓存内的数据可以分为4类：

• 已经发送并得到确认帧
• 已经发送还未收到确认帧
• 未发送但对端允许发送
• 未发送且对端不允许发送

已经发送还未收到确认帧、未发送但对端允许发送就是发送窗口

其中黑框部分就是发送窗口。

对于TCP的接收方

收到发送方的数据帧后，接收窗口向前移动一个帧位置，并发回确认帧到发送端，若收到的数据帧不在接收窗口内，则丢弃。

接收缓存内的数据可以分为3类：

• 已接收数据帧
• 未接受准备接收
• 未接受且为准备接收

未接受准备接收就是接收窗口

其中黑框部分就是接收窗口。

重要性

1. 只有接收窗口向前滑动，并且发送了确认帧到发送端时，发送窗口可以向前滑动
2. 当接收窗口的大小为1时，可以保证帧有序接收

自动重传协议ARQ

分为以下3类：

• 停止-等待协议：发送窗口大小为1，接收窗口大小为1；单帧滑动窗口

  发送方每发送一帧，要等到接收方返回的确认帧才可以继续发送下一帧

  接收方每接收一帧，都要返回一个确认帧到发送方，表示可以接收下一帧

  接收方不返回确认帧，发送方一直等待

• 后退N帧协议：发送窗口大小>1，接收窗口大小为1

  发送方连续发送多个数据帧，不需要等到接收方确认

  接收方采用累计确认&后退N帧的原理，只允许按顺序接收帧

  累计确认：收到多个数据帧后，只对按顺序到达的最后一帧发送确认帧，不必所有都去发送确认帧

  后退N帧：退回已发送过的N帧

• 选择重传协议：发送窗口大小>1，接收窗口大小>1

  发送方连续发送多个数据帧，不需要等到接收方确认

  接收窗口与发送窗口一样大，接收窗口直到数据填满再返回确认帧，否则需要发送方进行重传。

流量控制&拥塞控制

流量控制

接收方根据自己接收缓存的大小，动态调整发送窗口大小，从而控制发送方的发送速率。

容易出现死锁问题。当报文段在传送过程中丢失时，此时会出现发送方一直等待接收 接收方的非零窗口通知，然后接收方一直在等待发送方的数据，形成了死锁。

解决方案：TCP为每一个连接设有一个持续计时器(persistence timer)，只要TCP连接的一方收到对方的零窗口通知，就启动该计时器，若计时器计时结束，就会发出一个零窗口探测报文段。对方就会给出此时的窗口值：为0则需重新设置计时器，不为0 就要打破死锁。

拥塞控制

防止过多的数据注入到网络中，使得网络中的路由器和链路不至于过载。

具体解决方案分为两种：

慢开始和拥塞避免

慢开始

当主机开始发送数据时，由小到大逐渐增大拥塞窗口(发送窗口)数值，从而由小到大逐渐增大发送报文段。

拥塞避免

使得拥塞窗口按线性规律缓慢增长；没经过一个往返时间RTT，发送方的拥塞窗口加1。

快重传和快恢复

快重传

接收方 每收到一个失序的报文段后，就立即发出重复确认，而不是等到自己发出数据时再带上确认数据

发送方 只要连续收到3个重复确认就立即重传对方尚未收到的报文段，不必等到设置的重传计时器到点。

快恢复

是一个非常激进的算法。

先执行乘法减小算法，设置慢开始门限(ssthresh)为当前发送窗口大小的一半

再设置拥塞窗口(cwnd)为慢开始门限(ssthresh)的一半

再执行加法增大算法，执行拥塞避免算法，线性加大发送窗口。

UDP协议

User Datagram Protocol——用户数据报协议 主要用于传输层

特点

UDP特点	具体描述
无连接	使用UDP传输数据，不需要建立连接
不可靠	UDP的数据包发送后，不管其是否会到达接收方
面向报文	数据 以数据报文(包)的形式传输
无拥塞控制	由于是不可靠传输，不管是否到达接收方，所以不需要拥塞控制

优缺点

优点：速度快

缺点：消息易丢失(尤其是网络较差时)

应用场景

要求通信速度快，且不在乎结果。

域名转换 DNS协议、文件传输 FTP协议

当前的游戏、视频、即时通信工具也多用UDP协议传输数据，但也会辅以TCP协议进行数据完善。

报文段格式

分为两部分：首字段、数据字段。

字段	作用	描述
源端口	源端口号，需要对方回信时使用
目的端口	目的端口号，终点交付报文时使用
长度	UDP用户数据报的长度	最小值 8
校验和	检测UDP用户数据报在传输中是否有错	出错则丢弃
伪首部	计算校验和（不会发送出去）	不在UDP首部范围

与TCP协议的区别

1. TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接
2. TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保 证可靠交付
3. TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的，UDP没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）
4. 每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信
5. TCP首部开销20字节;UDP的首部开销小，只有8个字节
6. TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道

HTTP协议

HyperText Trsnsfer Protocol——超文本传输协议 主要用于应用层。基于TCP协议传输，端口号为80

HTTP是一个在计算机世界专门在两点之间传输文字，图片、音频等超文本数据的约定与规范。

版本

HTTP1.0

• 默认短连接
• 除了GET命令外还增加了POST、HEAD命令

HTTP1.1 (目前最流行版本)

• 默认长连接
• 增加更多的请求头和响应头
• 增加身份认证、状态管理功能
• 支持分块传输编码

HTTP2.0

• 新的二进制格式：之前都是用解析文本的方式
• 多路复用
• 服务端推送：在客户端请求资源时，会把相关资源一起发给客户端，就不需要客户端再次请求。
• 消息头压缩：客户端和服务端同时维护和更新一个首部字段表，避免重复传输

响应状态码

位于服务端返回响应报文中的第一行，包含了状态码以及原因短语，用来告知客户端请求结果。

状态码	类别	含义
1XX	Informational(信息性状态码)	接收请求正在处理
2XX	Success(成功状态码)	请求正常处理完毕
3XX	Redirection(重定向状态码)	需要进行附加操作完成请求
4XX	Client Error(客户端错误状态码)	服务器无法处理请求
5XX	Server Error(服务端错误状态码)	服务器处理请求出错

1XX 信息性状态码

• 100 Continue ：客户端继续发送请求

2XX 成功状态码

• 200 OK：请求成功
• 204 No Content：请求成功处理，但没有返回数据
• 206 Partial Content：客户端进行了范围请求，响应报文包含了Content-Range

3XX 重定向状态码

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

4XX 客户端错误状态码

• 400 Bad Request：请求报文存在语法错误
• 401 Unauthorized：用户认证失败
• 403 Frobidden：请求拒绝
• 404 Not Found

5XX 服务端出错状态码

• 500 Internal Server Error：服务器执行请求时发生错误
• 503 Server Unavaliable：服务器无法处理请求

HTTP请求方法

位于请求报文第一行，包含了方法字段

请求方法	作用	描述
GET	获取资源	客户端需要从服务器读取资源时使用 一般用于获取/查询信息 通过URL传递且参数长度是有限制的 请求格式 /test/result?key=key&page=1 请求是安全的，因为只读，不会改变服务器数据
POST	传输实体主体	客户端向服务端提供信息时使用 可以附带数据，用于更新服务器数据 将请求参数封装在请求数据中，可传输大量数据 传参方式更加安全，但是请求是不安全的，会导致服务器数据发生改变
HEAD	获取报文首部	不返回报文实体部分，主要用于确认URL有效性以及资源更新日期
PUT	上传文件	自身不带验证机制，存在安全性问题。一般不使用
PATCH	对资源部分进行修改	可以部分对资源进行修改
DELETE	删除文件	自身不带验证机制，存在安全性问题。
OPTIONS	查询支持的方法	查询指定的URL可以提供的方法。 返回示例：Allow: GET , POST
CONNECT	要求与代理服务器通信时建立隧道	对通信内容进行加密后通过网络隧道传输
TRACE	追踪路径	将通信路径返回给客户端

HTTP报文结构

分为两部分：

• 请求报文：用于发送请求时
• 响应报文：用于响应请求时

请求报文

请求行

声明请求方法、主机域名和协议版本

基本格式： Method Request-URI HTTP-Version CRLF

Method：表示请求方法，例如GET、POST...

Request-URI：统一资源标识符，例如https://leo-wxy.github.io/

HTTP-Version：HTTP协议版本，例如HTTP/1.1 HTTP/2.0

CRLF：表示回车和换行，\r\n

示例数据： GET http://leo-wxy.github.io/ HTTP/1.1

请求头

声明客户端、服务器/报文的部分信息

基本格式：header(字段名) : value(值)

报文通用Header(可用于请求报文和响应报文)

首部字段名	描述
Cache-Control	控制缓存的行为
Connection	允许发送指定连接的选项。例如close响应完成后，关闭服务器
Date	表示消息产生的日期和时间

请求报文Header

首部字段名	描述
Host	请求资源所在服务器
User-Agent	HTTP客户端程序的信息
Accept	用户可处理的媒体类型
Authorization	Web认证信息
Accept-Encoding	优先的内容编码

POST请求时的实体首部字段

首部字段名	描述
Allow	可支持的HTTP方法
Content-Length	请求体/响应体的长度，单位字节
Content-Type	请求体/响应体的类型，例如text/html

请求数据(请求体)

存放客户端发送给服务器的数据信息，如果为GET请求则没有该结构

使用方式共3种：

• 数据交换
• 键值对
• 分部分形式

请求报文示例

请求行	GET /test/index.html HTTP/1.1
请求头	Host : www.github.io
	User-Agent : Mozilla/5.0
空行	(用于隔开请求头和请求体)
请求体	id=0&page=1

响应报文

状态行

声明协议版本、状态码和描述

基本格式： HTTP-Version Status-Code Reason-Parse CRLF

HTTP-Version：HTTP协议版本，例如HTTP/1.1 HTTP/2.0

Status-Code：服务器返回的状态码，对应上面的响应状态码

Reason-Parse：状态码的文本描述，对应上面的响应状态码

CRLF：表示回车和换行，\r\n

示例数据： HTTP/1.1 404 Not Found

响应报头

声明客户端，服务端报文的部分信息

基本格式：header(字段名) : value(值)

常见响应报头Header

首部字段名	描述
Location	客户端重定向URL，用在更换域名时
Server	HTTP服务器的安装信息，与User-Agent是对应的
Age	推算资源创建经过的时间

响应正文

存放返给客户端的数据信息

使用方式共3种：

• 数据交换
• 键值对
• 分部分形式

响应报文示例

状态行	HTTP/1.1 200 OK
响应报头	Connection : keep-alive
	Server : Nginx
空行	(用于隔开响应头和响应正文)
响应正文	{“error”:false,”result”:1}

Cookie

HTTP/1.1中引入了Cookie来保存状态信息。

Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器之后向同一服务器再次发起请求时被带上，用于告知服务器两个请求来自同一浏览器。每次都携带，会带来额外的性能开销。

长连接

HTTP/1.1之后默认支持长连接。数据传输完成后TCP连接不会断开，继续使用该通道传输数据。

如何建立长连接？

设置HTTP Header：Connection

Connection对应两种值：Connection : close 或 Connection ： Keep-Alive

close：表示不使用长连接

keep-alive：表示开启长连接，还有两个Header设置长连接相关属性

• Keep-Alive:max：设置连接失败最大尝试次数，超过则断开
• Keep-Alive:time：设置最大超时时间，超过则断开

关闭长连接

• 判断传输数据是否达到了Content-Length指示的大小
• 根据chunked编码判断，若chunked编码在最后有一个空块，表明本次传输结束

HTTPS

HTTP有以下安全问题：

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

HTTPS是建立在SSL/TLS安全协议上的，这套协议运行在TCP协议上；会对传输的内容进行加密；使用端口443。

通过使用SSL，HTTPS就具有了加密(防窃听)、认证(防伪装)，完整性保护(防止报文被篡改)功能。

加密

对称密钥加密

加密和解密使用同一密钥。

优点：运算速度快

缺点：无法安全的将密钥传给客户端，安全性不高

具体算法：

DES算法，RC5算法、AES算法

非对称密钥加密

加密和解密使用不同的密钥。分别是公钥，私钥。

公钥所有人都可以获得，通信方得到公钥后，就可以对发送内容进行加密，然后传递至服务端，服务端就可以利用私钥进行解密。

私钥还可以对服务端返回内容进行签名，利用公钥去验证签名是否正确，防止被人篡改。

优点：可以更安全的将公钥传输给客户端，服务端持有私钥，不会暴露

缺点：加密解密速度慢

具体算法：

RSA算法

HTTPs采用的加密方式

HTTPS采用了混合加密机制，使用非对称闭钥的公钥加密对称密钥来保证传输的安全性，之后服务端使用私钥解密出对称加密密钥，然后双方使用对称密钥来加密报文进行互相传输。

步骤1：客户端发起HTTPS请求

步骤2：服务端配置非对称加密的公钥、私钥

步骤3：传送公钥到客户端

步骤4：客户端判断公钥是否有效，无效则显示警告。证书没有问题则会生成一个随机值，使用传递的公钥进行加密

步骤5：客户端传送加密后的随机值到服务端

步骤6：服务端使用私钥解密传递过来的数据，得到客户端生成的随机值，利用该随机值对传输数据进行加密

步骤7：服务端传输加密后的数据到客户端

步骤8：客户端使用上次生成的随机值对服务端传输的数据进行解密,整套流程结束。

中间人攻击

服务端在传输公钥的时候，可能中途被拦截，然后中间人对公钥进行篡改。这时在向下传递的公钥就完全是错误的，导致后续流程全部产生问题。

认证

通过使用证书来对通信方进行认证。

数字证书认证机构(CA,Certificate Authority)是客户端和服务端都可以信任的第三方机构。

服务端向CS申请公钥，CA对申请者身份认证通过后，会对公钥进行数字签名，然后分配公钥，再将公钥与证书进行绑定。进行HTTPS通信时，服务器吧证书也发给客户端，客户端可以利用证书对传递的公钥进行验证，验证通过后就可以继续后续的通信。

完整性保护

SSL提供报文摘要功能进行完整性保护。

HTTP的报文摘要功能是通过MD5实现的，中途被篡改了，然后重新MD5，客户端是无法感知内容已经发送变化。

HTTPs 的报文摘要功能之所以安全，是因为它结合了加密和认证这两个操作。试想一下，加密之后的报文，遭到篡改之后，也很难重新计算报文摘要，因为无法轻易获取明文。

HTTPS缺点

1. HTTPS协议握手阶段比较费时，因为需要进行加密/解密过程
2. SSL证书是需要钱的，越高级的越贵
3. HTTPS加密范围有限，而且证书也不是一定可以完全信任的。

Socket

Socket是通信的基石，是对TCP/IP协议的封装，是接口而非协议。创建Socket连接时可以指定传输层协议TCP或者UDP；

Socket建立连接过程分为三步：

1. 服务端监听
2. 客户端请求
3. 连接确认

应用层可以和传输层通过Socket，区分来自不同应用程序进程或网络连接的通信，实现数据传输的并发服务。

DNS协议

其他

地址栏中输入url会发生什么

• 浏览器向DNS服务器请求解析该url中的域名对应的IP地址
• 解析得到IP地址后，根据IP地址和端口，与服务器建立TCP连接
• 浏览器发出读取文件的HTTP请求
• 服务器对浏览器请求做出响应，返回html文本到浏览器
• 根据Header中的Connection判断是否需要释放TCP连接，若为close则关闭连接；为keep-alive则保持该连接一段时间，可以继续接受服务器数据
• 浏览器解析服务端返回的html文本并显示

CDN

全称为Content Delivery Network(内容分发网络)，使用到了HTTP协议里的缓存和代理技术，代替源站响应客户端的请求。

​

参考链接

计算机网络高频面试解析

HTTP协议