这几天翻了下图解TCP/IP，把网络相关的知识整理下。

主要包含以下内容：

• 网络基础知识

• tcp/ip基础知识

• tcp与udp

• http版本演化

• http响应码

• https

OSI参考模型

虽然ISO指定了一个国际标准OSI，对通信系统进行标准化。但是这个标准并没有得到普及，不过它的参考模型却用在了网络协议的制定中。

举一个例子。

tcp/ip 基础知识

TCP与UDP

TCP与UDP最大的区别，TCP是有状态，UDP是无状态，TCP是高可靠性通信，UDP主要是及时通信。

这里主要介绍tcp，包括：

• 特点介绍

• 首部格式

• 三次握手

• 数据发送

• 窗口控制

• 流控制

• 拥堵控制

• TCP拥堵（有点重复)

• 四次挥手

TCP报文头格式：

说明：

• 源端口：source port，发送端口号：16位

• 目标端口：destination port，接收端口号：16位

• 序列号：seq ，发送数据的位置，每发送一次累加：32位

• 确认应答号：ack，下次应该接收到的数据序列号：32位

• 数据偏移：TCP传输的数据从哪个位置开始计算，4bit

• 控制位 8位，依次是

• CWR

• ECE，为1，将拥堵窗口缩小

• URG，为1，表示包中有需要紧急处理的数据

• ACK，为1，确认应答的字段有效，必须设置为1

• PSH，为1，表示接收到的数据立即传给上层应用协议，为0时，先缓存

• RST，为1，表示TCP连接出现异常，必须强制断开

• SYN，为1，表示希望建立链接，握手完成置为0

• FIN，为1，表示今后不会再有数据发送，希望断开连接

• 窗口大小：16位，用于通知从相同TCP首部的确认应答号所指位置开始能够接收的数据大小

• 紧急指针

• 选项：长度可变

• 校验和：checksum

TCP三次握手和四次挥手以及数据发送

三次握手过程：

• ①，客户端发送syn包（syn=x）到服务器

• 客户端进入SYN_SENT状态，等待确认

• 同时还会请求设置MSS为4000

• ②，服务器应答ACK=1（ack=x+1）

• 发送一个SYN包（syn=y）和ACK包返回

• 服务器进入SYN_RECV状态

• 告诉客户端MSS为1000

• ③，客户端接收SYN+ACK包

• ack=x+2

• 客户端和服务端进入ESTABLISHED

• tcp连接成功

四次挥手过程

• ①，客户端发出FIN，请求断开

• FIN=1,seq=x

• 客户端进入FIN-WAIT-1状态

• 主动断开

• ②，服务端ACK

• ACK=1,ack=x+1,seq=y

• 服务端进入CLOSE-WAIT状态

• 客户端接收到后进入FIN-WAIT-2状态

• 服务端把要发的数据都发给客户端

• ③，服务端FIN，请求断开

• FIN=1,ACK=1,seq=z,ack=x+1

• 服务端进入LAST-ACK状态

• ④，客户端ACK

• 等待2*MSL（最长报文寿命）最长240秒后释放，可以调整

• ACK=1,seq=x+1,ack=z+1

• 服务端进入CLOSED立即释放

• 客户端进入TIME-WAIT

数据发送

• 正常发送通过seq能保证顺序以及数据的完整性

• 通过窗口控制，可以提高吞吐量，窗口控制也会带出一个高速重发控制，而不是等待超时再重发；

• 流控制通过服务器的负荷情况，调节客户端的窗口大小；

• 拥塞控制，为防止客户端突然发送较大量的数据，导致网络瘫痪，通过慢启动来逐步调节拥堵窗口的大小

为什么建立连接是三次握手，而不是两次握手？

• ACK能保证客户端和服务端是对等的，确保两台机器都没问题，防止客户端确认后服务端超时或断开

为什么建立是三次握手，而断开链接是四次挥手？

• 客户端想断开，可能服务端还有要返回的数据处理，如此服务端还有机会把未处理完的数据返回；

• 服务端处理完了发送关闭请求，这个时候才关闭，三次握手解决不了问题；

• 关闭还有主动关闭，两次握手解决；

• 这些都是TCP可靠性的保障

大量TIME-WAIT导致链接不够用

• 当系统压力较大的时候，特别时候网关或者服务调用外部服务的时候,因为需要2MSL时长才会关闭（120秒内）；

• 可以通过调整系统参数解决，降低回收时间

http版本演化

目前市场上主流用的还是http1.1

0.9版本

• 只有get，返回只能是html

1.0

• 新增post和head

• 一次请求就关闭

• 可以自定义context-type

1.1

• 新增put、patch、options、delete

• 引入持久链接（默认不关闭，可被复用）

• 支持断点续传

• 支持host与range头域（缓存的处理）
  未解决问题

• 明文传输

• header头部数据太长

• 每次传输需要重新连接

• server端不能主动push

2.0

• 是https协议的升级版

特点：

• 头信息和数据体都是二进制

• 复用tcp连接（netty的长链接）

• 引入头部压缩机制(grpc做固定映射，前后持有一个映射表)

• 允许主动push

https

基于http加了一层ssl/tls层。

为什么要加密？

• http明文传输不安全

• 经过中间代理服务器、路由器、wifi等容易被劫持

• 轻则挂广告，挂马

• 重则用户信息泄露

• 中间人攻击

• 可以劫持服务端信息，替换公钥，然后给客户端

• 之后劫持客户端信息，用自己的私钥解密，再用服务端的公钥加密

https通过CA机构颁发CA证书来完成加解密，流程

• 网站去ca机构申请数字证书

• ca证书内置持有者信息（域名）和公钥信息

• ca 机构会用自己的私钥将ca证书hash后，拿着hash结果生成一个数字签名，包括hash算法和签名信息

• 网站将证书内置到nginx或别的服务器里；

• 浏览器持有ca机构的公钥（ca对浏览器信任）

• 从ca证书里获取明文信息、签名信息和hash算法

• 通过内置的CA公钥对sign进行解密，得到散列值x1

• 再用证书里的hash算法对明文信息进行hash，得到x2

• x1=x2说明没有被篡改

• 中间人

• 浏览器会校验证书的归属，请求的host如果不是原来的，就无法通过

• 即使拿到ca的公钥，只能解密，没有ca私钥，无法再加密

• 篡改证书？

• 证书掉包？

常见http状态码

2xx 表示操作成功了

• 200 请求成功

• 201 请求被创建成功

• 202 请求已被接收，但未处理完（异步处理）

3xx 重定向

• 300 表示客户端需要做些额外的操作才能得到对应的资源

• 301 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替

• 302 请求资源临时转移到新url，客户端继续用原来的

• 303 请求已被处理，不会再返回对应的内容（直接返回之前的url）

• 304 未修改。表示页面有缓存的情况下，缓存可用

• css和图片服务器会自动完成last modifiled和if modified since

• 对于动态页面，我们要在Response的header中添加Last Modified 定义，如果有效，就返回304，不用再返回实际内容，减少服务器压力；

4xx：客户端错误

• 400 客户端请求的语法错误，服务器无法理解

• 401 请求要求用户的身份认证

• 403 请求的资源被禁止访问或拒绝执行

• 404 服务器无法找到请求的资源

• 405 请求中指定的方法不允许

5xx 服务端错误

• 500 通用的服务器错误响应

• 501 服务器不支持请求的功能

• 502 网关错误（上游收到一个无效的响应）

• 503 服务器当前不可用

• 504 网关超时

• 505 不支持请求中指明的http协议版本

xmind已经放入百度云盘和阿里云盘，后台回复任意消息可获取链接。