网络基础知识

一、网络篇

1、OSI七层协议开放式互联网参考模型

物理层

传输比特流 0101 （网卡）

数据链路层

解决错传，数据传输不完整的可能。将比特数据组成帧（交换机）

网络层

将网络地址翻译成对应的物理地址，并决定怎么把数据从发送方路由到接收方（路由器）
数据报 协议：IP协议

传输层

解决了主机间的数据传输，和传输质量的问题。

分段 协议：TCP协议，UDP协议

会话层

建立和管理应用程序之间的通信。应用程序能自动收发包和自动寻址。

表示层

信息的语法语义以及它们的关联，如加密解密，转换翻译，压缩解压缩。数据按照网络能理解的方案进行格式化。

应用层

规定发送方和接受方使用一个固定长度的消息头，消息头必须使用某种固定的组成，消息头中必须记录消息体的长度等一系列信息，以方便接受解析发送方发送的数据。

2、TCP的三次握手

传输控制协议TCP简介：

• 面向连接的、可靠的、基于字节流的传输层通信协议
• 将应用层的数据流分割成报文段并发送给目标节点的TCP层
• 数据包都有序号，对方收到则发送ACK确认，未收到则重传
• 使用校验和来校验数据在传输过程中是否有误

TCP Flags：

• URG：紧急指针标志
• ACK：确认序号标志
• PSH：push标志
• RST：重置连接标志
• SYN：同步序号，用于建立连接过程
• FIN：finish标志，用于释放连接

TCP三次握手流程图

抓包测试：

抓包软件：Wireshark

ip.dst==115.28.159.6 or ip.src==115.28.159.6 #正则表达式

TCP三次握手的流程

（1）“握手”是为了建立连接,在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

• 第一次握手:建立连接时，客户端发送SYN包（syn=j）到服务器，并进入SYN_SEND状态,等待服务器确认;
• 第二次握手:服务器收到SYN包,必须确认客户的SYN(ack=j+1),同时自己也发送一个SYN包(syn=k),即SYN+ACK包,此时服务器进入SYN_RECV状态;
• 第三次握手:客户端收到服务器的SYN+ ACK包,向服务器发送确认包ACK(ack=k+1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手。

（2）为什么需要三次握手才能建立连接？

为了初始化Sequence Number的初始值

（3）首次握手的隐患—SYN超时

问题起因分析

• Server收到Client的SYN ,回复SYN-ACK的时候未收到ACK确认
• Server不断重试直至超时, Linux默认等待63秒才断开连接

针对SYN Flood的防护措施

• SYN队列满后,通过tcp_syncookies参数回发SYN Cookie
• 若为正常连接则Client会回发SYN Cookie ,直接建立连接

（4）建立连接后，Client出现故障怎么办？

保活机制

• 向对方发送保活探测报文,如果未收到响应则继续发送
• 尝试次数达到保活探测数仍未收到响应则中断连接

3、TCP四次挥手

TCP四次挥手流程图

TCP四次挥手流程

“挥手”是为了终止连接,TCP采用四次挥手来释放连接：

• 第一次挥手: Client发送一个FIN,用来关闭Client到Server的数据传送，Client 进入FIN_WAIT_1状态;
• 第二次挥手: Server 收到FIN后，发送一个ACK给Client,确认序号为收到序号+1(与SYN相同，一个FIN占用一个序
  号)，Server 进入CLOSE_WAIT状态;
• 第三次挥手: Server发送一个FIN,用来关闭Server到Client的数据传送，Server 进入LAST_ACK状态;
• 第四次挥手: Client 收到FIN后，Client 进入TIME _WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,
  Server进入CLOSED状态，完成四次挥手。

（1）为什么会有TIME_ _WAIT状态？

• 确保有足够的时间让对方收到ACK包
• 避免新旧连接混淆

（2）为什么需要四次握手才能断开连接？

因为全双工，发送方和接收方都需要FIN报文和ACK报文

（3）服务器出现大量CLOSE_WAIT状态的原因？

对方关闭socket连接,我方忙于读或写,没有及时关闭连接

解决：

• 检查代码,特别是释放资源的代码
• 检查配置,特别是处理请求的线程配置

4、TCP和UDP的区别

UDP的特点

• 面向非连接
• 不维护连接状态,支持同时向多个客户端传输相同的消息
• 数据包报头只有8个字节,额外开销较小（TCP是20个字节）
• 吞吐量只受限于数据生成速率、传输速率以及机器性能
• 尽最大努力交付,不保证可靠交付,不需要维持复杂的链接状态表
• 面向报文,不对应用程序提交的报文信息进行拆分或者合并

TCP和UDP的区别

• 面向连接Vs无连接
• 可靠性VS无
• 有序性VS无
• 速度慢VS速度快
• 量级高VS量级低

5、TCP的滑动窗口

RTT和RTO

• RTT：发送一个数据包到收到对应的ACK，所花费的时间
• RTO：重传时间间隔

TCP使用滑动窗口做流量控制与乱序重排

• 保证TCP的可靠性
• 保证TCP的流动特性

详情可参考：TCP-IP详解：滑动窗口

6、HTTP

HTTP简介

超文本传输协议HTTP主要特点

• 支持客户/服务器模式
• 简单快速
• 灵活
• 无连接
• 无状态

HTTP请求结构

请求/响应的步骤

• 客户端连接到Web服务器
• 发送HTTP请求
• 服务器接受请求并返回HTTP响应
• 释放连接TCP连接
• 客户端浏览器解析HTML内容

在浏览器地址栏键入URL ,按下回车之后经历的流程:
DNS解析➢TCP连接➢发送HTTP请求➢服务器处理请求并返回HTTP报文➢浏览器解析渲染页面➢连接结束

HTTP状态码

• 1xx :指示信息–表示请求已接收,继续处理
• 2xx :成功–表示请求已被成功接收、理解、接受
• 3xx :重定向–要完成请求必须进行更进一步的操作
• 4xx:客户端错误–请求有语法错误或请求无法实现
• 5xx :服务器端错误-服务器未能实现合法的请求

常见状态码

• 200 OK:正常返回信息
• 400 Bad Request:客户端请求有语法错误，不能被服务器所理解
• 401 Unauthorized:请求未经授权，这个状态代码必须和WWW-Authenticate报头域一起使用
• 403 Forbidden:服务器收到请求，但是拒绝提供服务
• 404 Not Found:请求资源不存在，eg，输入了错误的URL
• 500 Internal Server Error:服务器发生不可预期的错误
• 503 Server Unavailable:服务器当前不能处理客户端的请求，一段时间后可能恢复正常

HTTP/1.1、HTTP/2、HTTP/3的比较

HTTP/1.1的缺陷

高延迟–带来页面加载速度的降低

虽然近几年来网络带宽增长非常快，然而我们却并没有看到网络延迟有对应程度的降低。网络延迟问题主要由于队头阻塞(Head-Of-Line Blocking),导致带宽无法被充分利用。

队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。针对队头阻塞,人们尝试过以下办法来解决:

1. 将同一页面的资源分散到不同域名下，提升连接上限。 Chrome 有个机制，对于同一个域名，默认允许同时建立 6 个 TCP 持久连接，使用持久连接时，虽然能公用一个 TCP 管道，但是在一个管道中同一时刻只能处理一个请求，在当前的请求没有结束之前，其他的请求只能处于阻塞状态。另外如果在同一个域名下同时有 10 个请求发生，那么其中 4 个请求会进入排队等待状态，直至进行中的请求完成。
2. 雪碧图(Spriting)合并多张小图为一张大图,再用 JavaScript 或者 CSS 将小图重新“切割”出来的技术。
3. 内联(Inlining)是另外一种防止发送很多小图请求的技巧，将图片的原始数据嵌使用 SVG 或 base64 等方式直接存储在代码中，减少网络请求次数。
4. 拼接(Concatenation)将多个体积较小的 JavaScript 使用 webpack 等工具打包成 1 个体积更大的 JavaScript 文件,但如果其中 1 个文件的改动就会导致大量数据被重新下载多个文件。

无状态特性–带来的巨大 HTTP 头部

由于报文 Header 一般会携带"User Agent" "Cookie" "Accept" "Server"等许多固定的头字段，多达几百字节甚至上千字节，但 Body 却经常只有几十字节（比如 GET 请求、 204/301/304 响应），成了不折不扣的“大头儿子”。Header 里携带的内容过大，在一定程度上增加了传输的成本。更要命的是，每次网络请求响应报文里有很多字段值都是重复的，非常浪费。

3.明文传输–带来的不安全性

HTTP/1.1 在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。

你有没有听说过”免费 WiFi 陷阱”之类的新闻呢？ 黑客就是利用了 HTTP 明文传输的缺点，在公共场所架设一个 WiFi 热点开始“钓鱼”，诱骗网民上网。一旦你连上了这个 WiFi 热点，所有的流量都会被截获保存，里面如果有银行卡号、网站密码等敏感信息的话那就危险了，黑客拿到了这些数据就可以冒充你为所欲为。

HTTP/2 特性

二进制传输

HTTP 2.0 中所有加强性能的核心点在于此。在之前的 HTTP 版本中，我们是通过文本的方式传输数据。在 HTTP 2.0 中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码，二进制协议解析起来也更高效。

它把 TCP 协议的部分特性挪到了应用层，把原来的”Header+Body”的消息”打散”为数个小片的二进制”帧”(Frame), 用”HEADERS”帧存放头数据、”DATA”帧存放实体数据。HTTP/2 数据分帧后”Header+Body”的报文结构就完全消失了，协议看到的只是一个个的”碎片”。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

Header 压缩

在 HTTP 1.X 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。

在 HTTP 2.0 中，使用了 HPACK 压缩格式对传输的 header 进行编码，客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串，可以达到 50%~90%的高压缩率

在客户端和服务器端使用“首部表”来跟踪和存储之前发送的 header 键-值对，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。

多路复用

HTTP1.x 中，并发多个请求需要多个 TCP 连接，浏览器为了控制资源会有 6-8 个 TCP 连接都限制。 HTTP2 中：

• 同域名下所有通信都在单个连接上完成，消除了因多个 TCP 连接而带来的延时和内存消耗
• 单个连接可以承载任意数量的双向数据流（请求和响应）
• 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。

帧（frame）和流（stream）

• 帧代表着最小的数据单位，每个帧会标识出该帧属于哪个流，流也就是多个帧组成的数据流。

多路复用，就是在一个 TCP 连接中可以存在多条流。 换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能。

服务端 Push

在 HTTP 2.0 中，服务端可以在客户端某个请求后，主动推送其他资源。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为”服务器推送”（ Server Push，也叫 Cache push）

提前给客户端推送必要的资源，这样就可以相对减少一点延迟时间。服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送 RST_STREAM 帧来拒收。主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。

提高安全性

但由于 HTTPS 已经是大势所趋，而且主流的浏览器 Chrome、Firefox 等都公开宣布只支持加密的 HTTP/2，所以“事实上”的 HTTP/2 是加密的。也就是说，互联网上通常所能见到的 HTTP/2 都是使用”https”协议名，跑在 TLS 上面。

HTTP/2 协议定义了两个字符串标识符：“h2”表示加密的 HTTP/2，“h2c”表示明文的 HTTP/2。

GET请求和POST请求的区别

• Http报文层面: GET将请求信息放在URL , POST放在报文体中
• 数据库层面: CET符合幂等性和安全性, POST不符合
• 其他层面: GET可以被缓存、被存储,而POST不行

Cookie和Session的区别

Cookie简介

• 是由服务器发给客户端的特殊信息,以文本的形式存放在客户端
• 客户端再次请求的时候,会把Cookie回发
• 服务器接收到后,会解析Cookie生成与客户端相对应的内容

Cookie的设置及发送过程

Session简介

• 服务器端的机制,在服务器上保存的信息
• 解析客户端请求并操作session id ,按需保存状态信息

Session的实现方式

Cookie和Session的区别

• Cookie数据存放在客户的浏览器上, Session数据放在服务器上
• Session相对于Cookie更安全
• 若考虑减轻服务器负担,应当使用Cookie

HTTP和HTTPS的区别

HTTPS简介

SSL(Security Sockets Layer ,安全套接层)

• 为网络通信提供安全及数据完整性的一种安全协议
• 是操作系统对外的API , SSL3.0后更名为TLS
• 采用身份验证和数据加密保证网络通信的安全和数据的完整性

加密的方式

• 对称加密:加密和解密都使用同-个密钥
• 非对称加密:加密使用的密钥和解密使用的密钥是不相同的
• 哈希算法:将任意长度的信息转换为固定长度的值 ,算法不可逆
• 数字签名:证明某个消息或者文件是某人发出/认同的

HTTPS数据传输流程

• 浏览器将支持的加密算法信息发送给服务器
• 服务器选择一套浏览器支持的加密算法,以证书的形式回发浏览器
• 浏览器验证证书合法性,并结合证书公钥加密信息发送给服务器
• 服务器使用私钥解密信息,验证哈希,加密响应消息回发浏览器
• 浏览器解密响应消息,并对消息进行验真,之后进行加密交互数据

HTTP和HTTPS的区别

• HTTPS需要到CA申请证书, HTTP不需要
• HTTPS密文传输, HTTP明文传输
• 连接方式不同,HTTPS默认使用443端口, HTTP使用80端口
• HTTPS=HTTP+加密+认证+完整性保护,较HTTP安全

HTTPS真的很安全吗？

那倒未必

• 浏览器默认填充http:// ,请求需要进行跳转,有被劫持的风险
• 可以使用HSTS ( HTTP Strict Transport Security )优化

7、Socket

Socket简介

我们知道两个进程如果需要进行通讯最基本的一个前提是能够唯一的标示一个进程，在本地进程通讯中我们可以使用PID来唯一标示一个进程，但PID只在本地唯一，网络中的两个进程PID冲突几率很大，这时候我们需要另辟它径了，我们知道IP层的ip地址可以唯一标示主机，而TCP层协议和端口号可以唯一标示主机的一个进程，这样我们可以利用ip地址＋协议＋端口号唯一标示网络中的一个进程。

能够唯一标示网络中的进程后，它们就可以利用socket进行通信了，什么是socket呢？我们经常把socket翻译为套接字，socket是在应用层和传输层之间的一个抽象层，它把TCP/IP层复杂的操作抽象为几个简单的接口供应用层调用已实现进程在网络中通信。

socket起源于UNIX，在Unix一切皆文件哲学的思想下，socket是一种”打开—读/写—关闭”模式的实现，服务器和客户端各自维护一个”文件”，在建立连接打开后，可以向自己文件写入内容供对方读取或者读取对方内容，通讯结束时关闭文件。

Socket通信流程

socket是”打开—读/写—关闭”模式的实现，以使用TCP协议通讯的socket为例，其交互流程大概是这样子的：

CDN

定义：CDN（Content Delivery Network，内容分发网络）是构建在现有互联网基础之上的一层智能虚拟网络，通过在网络各处部署节点服务器，实现将源站内容分发至所有 CDN 节点，使用户可以就近获得所需的内容。

优点：

• CDN 服务缩短了用户查看内容的访问延迟
• 提高了用户访问网站的响应速度与网站的可用性
• 解决了网络带宽小、用户访问量大、网点分布不均等问题

加速原理

当用户访问使用CDN服务的网站时，本地DNS服务器通过CNAME方式将最终域名请求重定向到CDN服务。CDN通过一组预先定义好的策略（如内容类型、地理区域、网络负载状况等）将当时能最快响应用户的CDN节点IP地址提供用户，使用户可以以最快的速度获得网站内容。使用CDN后的HTTP请求处理流程如下：

CDN节点有缓存场景

1. 用户在浏览器输入要访问的网站域名，向本地 DNS 发起域名解析请求。
2. 域名解析的请求被发往网站授权 DNS 服务器。
3. 网站 DNS 服务器解析发现域名已经 CNAME 到了 www.example.com.c.cdnhwc1.com。
4. 请求被指向 CDN 服务。
5. CDN 对域名进行智能解析，将响应速度最快的 CDN 节点 IP 地址返回给本地 DNS。
6. 用户获取响应速度最快的 CDN 节点 IP 地址。
7. 浏览器在得到速度最快节点的 IP 地址以后，向 CDN 节点发出访问请求。
8. CDN 节点将用户所需资源返回给用户。

CDN节点无缓存场景

1. 用户在浏览器输入要访问的网站域名，向本地 DNS 发起域名解析请求。
2. 域名解析的请求被发往网站授权 DNS 服务器。
3. 网站 DNS 服务器解析发现域名已经 CNAME 到了 www.example.com.c.cdnhwc1.com。
4. 请求被指向 CDN 服务。
5. CDN 对域名进行智能解析，将响应速度最快的 CDN 节点 IP 地址返回给本地 DNS。
6. 用户获取响应速度最快的 CDN 节点 IP 地址。
7. 浏览器在得到速度最快节点的 IP 地址以后，向 CDN 节点发出访问请求。
8. CDN 节点回源站拉取用户所需资源。
9. 将回源拉取的资源缓存至节点。
10. 将用户所需资源返回给用户。