攻略大全

1. 粘贴攻略

1.1 计算机网络体系结构

1.1.1 简介

定义：计算机网络的各层+其协议的组合

作用：定义该计算机网络所能完成的功能

1.1.2 结构介绍

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

OSI体系结构：概念清楚、理念完整，但是复杂且不实用

TCP/IP体系结构：包含了一系列构成互联网基础的网络协议，是Internet的核心协议，被广泛应用于局域网和广域网。

五层体系结构：融合了OSI与TCP/IP的体系结构，目的是为了学习与讲解计算机原理。

1.1.2.1 详解TCP/IP

1.1.2.2 详解OSI

1.2 HTTP协议

HTTP协议采用请求 / 响应的工作方式，具体工作流程如下：

1.2.1 HTTP的优缺点

1.2.1.1 优点

无连接、无状态、灵活、简单快速

无连接：每一次请求都要连接一次，请求结束就会断掉，不会保持连接。
无状态：每一次请求都是独立的，请求结束不会记录连接的任何信息，减少了网络开销，这是优点也是缺点。
灵活：通过http协议中头部的Content-Type标记，可以传输任意数据类型的数据对象(文本、图片、视频等等)，非常灵活。
简单快速：发送请求访问某个资源时，只需传送请求方法和URL就可以了，使用简单，正由于http协议简单，使得http服务器的程序规模小，因而通信速度很快。

1.2.1.2 缺点

无状态、不安全、明文传输、队头阻塞

无状态：请求不会记录任何连接信息，没有记忆，就无法区分多个请求发起者身份是不是同一个客户端的，意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。
不安全：明文传输可能被窃听不安全，缺少身份认证也可能遭遇伪装，还有缺少报文完整性验证可能遭到篡改。
明文传输：报文(header部分)使用的是明文，直接将信息暴露给了外界，WIFI陷阱就是复用明文传输的特点，诱导你连上热点，然后疯狂抓取你的流量，从而拿到你的敏感信息。
队头阻塞：开启长连接时，只建立一个TCP连接，同一时刻只能处理一个请求，那么当请求耗时过长时，其他请求就只能阻塞状态。

1.2.2 HTTP报文组成部分

HTTP在应用层交互数据的方式 = 报文
HTTP的报文分为：请求报文 & 响应报文

分别用于发送请求 & 响应请求时

1.2.2.1 请求报文

报文结构

HTTP的请求报文由请求行、请求头 & 请求体组成，如下图

1.2.2.1.1 组成1：请求行

作用

声明请求方法、主机域名、资源路径 & 协议版本
结构

请求行的组成 = 请求方法 + 请求路径 + 协议版本

注：空格不能省

组成介绍

此处特意说明GET、PSOT方法的区别：

示例

设：请求报文采用GET方法、 URL地址 = www.tsinghua.edu.cn/chn/yxsz/in…；、HTTP1.1版本

则请求行是：GET /chn/yxsz/index.htm HTTP/1.1

1.2.2.1.2 组成2：请求头

作用：声明客户端、服务器 / 报文的部分信息
使用方式：采用”header（字段名）：value（值）“的方式
常用请求头

1. 请求和响应报文的通用Header

2. 常见请求Header

1.2.2.1.3 组成3：请求体

作用：存放需发送给服务器的数据信息

可选部分，如 GET请求就无请求数据

使用方式：共3种

1.2.1.1.4 请求报文总结

1.2.2.2 响应报文

报文结构

HTTP的响应报文包括：状态行、响应头 & 响应体

其中，响应头、响应体与请求报文的请求头、请求体类似
这2种报文最大的不同在于状态行 & 请求行

1.2.2.2.1 组成1：状态行

作用

声明协议版本，状态码，状态码描述
组成

状态行有协议版本、状态码 &状态信息组成

其中，空格不能省

具体介绍
状态行示例

HTTP/1.1 202 Accepted(接受)、HTTP/1.1 404 Not Found(找不到)

1.2.2.2.2 组成2：响应头

作用：声明客户端、服务器 / 报文的部分信息
使用方式：采用”header（字段名）：value（值）“的方式
常用请求头

1. 请求和响应报文的通用Header

2. 常见响应Header

1.2.2.2.3 组成3：响应体

作用：存放需返回给客户端的数据信息
使用方式：和请求体是一致的，同样分为：任意类型的数据交换格式、键值对形式和分部分形式

1.2.2.2.4 响应报文总结

1.2.2.3 HTTP报文总结

1.2.3 HTTP 请求方法(9种)

HTTP1.0： GET、POST、HEAD

HTTP1.1： PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT

方法	描述
GET	获取资源
POST	传输资源，通常会造成服务器资源的修改
HEAD	获得报文首部
PUT	更新资源
PATCH	对PUT的补充，对已知资源部分更新
DELETE	删除资源
OPTIONS	列出请求资源支持的请求方法，用来跨域请求
TRACE	追踪请求/响应路径，用于测试或诊断
CONNECT	将连接改为管道方式用于代理服务器

1.2.4 GET 和 POST 的区别

GET在浏览器回退时是无害的，而POST会再次发起请求
GET请求会被浏览器主动缓存，而POST不会，除非手动设置
GET请求参数会被保留在浏览器历史记录里，而POST中的参数不会被保留
GET请求在URL中传递的参数有长度限制(浏览器限制大小不同)，而POST没有限制
GET参数通过URL传递，POST放在Request body中
GET产生的URL地址可以被收藏，而POST不可以
GET没有POST安全，因为GET请求参数直接暴露在URL上，所以不能用来传递敏感信息
GET请求只能进行URL编码，而POST支持多种编码方式
对参数的数据类型，GET只接受ASCII字符，而POST没有限制
GET产生一个TCP数据包，POST产生两个数据包(Firefox只发一次)。GET浏览器把 http header和data一起发出去，响应成功200，POST先发送header，响应100 continue，再发送data，响应成功200

1.2.5 常见 HTTP 状态码

1xx: 指示信息——表示请求已接收，继续处理

2xx: 成功——表示请求已被成功接收

3xx: 重定向——表示要完成请求必须进行进一步操作

4xx: 客户端错误——表示请求有语法错误或请求无法实现

5xx: 服务端错误——表示服务器未能实现合法的请求

状态码	描述
200	请求成功
206	已完成指定范围的请求(带Range头的GET请求),场景如video,audio播放文件较大,文件分片时
301	永久重定向
302	临时重定向
304	请求资源未修改，可以使用缓存的资源，不用在服务器取
400	请求有语法错误
401	没有权限访问
403	服务器拒绝执行请求，场景如不允许直接访问，只能通过服务器访问时
404	请求资源不存在
500	服务器内部错误，无法完成请求
503	请求未完成，因服务器过载、宕机或维护等

1.2.6 什么是持久连接/长连接

Keep-Alive模式(又称持久连接，连接复用)建立一个TCP连接后使客户端到服务端的连接持续有效，可以发送/接受多个http请求/响应，当出现对服务器的后续请求时，Keep-Alive功能避免了建立或者重新建立连接。

http1.0协议采用的是"请求-应答"模式，当使用普通模式，每个请求/应答客户与服务器都要新建一个连接，完成之后立即断开连接(http协议为无连接的协议)。http1.0中keep-alive默认是关闭的，需要在HTTP头加入"Connection: Keep-Alive"，才能启用Keep-Alive。

http1.1版本默认支持长连接，即默认启用Keep-Alive，如果加入"Connection: close "，才关闭。

1.2.6.1 长连接的优点

减少CPU及内存的使用，因为不需要经常建立和关闭连接
支持管道化的请求及响应模式
减少网络堵塞，因为减少了TCP请求
减少了后续请求的响应时间，因为不需要等待建立TCP、握手、挥手、关闭TCP的过程
发生错误时，也可在不关闭连接的情况下进行错误提示

1.2.6.2 长连接的缺点

一个长连接建立后，如果一直保持连接，对服务器来说非常的浪费资源，而且长连接时间的长短，直接影响到服务器的并发数。

还有就是可能造成队头堵塞，造成信息延迟。

1.2.6.3 如何避免长连接资源浪费？

客户端请求头声明：Connection: close，本次通信后就关闭连接
服务端配置：如Nginx，设置keepalive_timeout设置长连接超时时间，keepalive_requests设置长连接请求次数上限
系统内核参数设置：
- net.ipv4.tcp_keepalive_time = 60，连接闲置60秒后，服务端尝试向客户端发送侦测包，判断TCP连接状态，如果没有收到ack反馈就在
- net.ipv4.tcp_keepalive_intvl = 10，就在10秒后再次尝试发送侦测包，直到收到ack反馈，一共会
- net.ipv4.tcp_keepalive_probes = 5，一共会尝试5次，要是都没有收到就关闭这个TCP连接了

1.2.7 什么是管线化(管道化)

http1.1在使用长连接的情况下，建立一个连接通道后，连接上消息的传递类似于：

请求1 -> 响应1 -> 请求2 -> 响应2 -> 请求3 -> 响应3

管线化连接的消息就变成了类似这样：

请求1 -> 请求2 -> 请求3 -> 响应1 -> 响应2 -> 响应3

管线化是在同一个TCP连接里发一个请求后不必等其回来就可以继续发请求出去，这可以减少整体的响应时间，但是服务器还是会按照请求的顺序响应请求，所以如果有许多请求，而前面的请求响应很慢，就产生一个著名的问题队头堵塞。

管线化的特点：

管线化机制通过持久连接完成，在http1.1版本才支持
只有GET请求和HEAD请求才可以进行管线化，而POST有所限制
初次创建连接时不应启动管线化机制，因为服务器不一定支持http1.1版本的协议
管线化不会影响响应到来的顺序，如上面的例子所示，响应返回的顺序就是请求的顺序
要求客户端和服务端都支持管线化，但并不要求服务端也对响应进行管线化处理，只是要求对于管线化的请求不失败即可
由于上面提到的服务端问题，开启管线化很可能并不会带来大幅度的性能提升，而且很多服务端和代理程序对管线化的支持并不好，因此浏览器(Chrome/Firefox)默认并未开启管线化支持

1.2.8 如何解决 HTTP 的队头阻塞问题

http1.0协议采用的是请求-应答模式，报文必须是一发一收，就形成了一个先进先出的串行队列，没有轻重缓急的优先级，只有入队的先后顺序，排在最前面的请求最先处理，就导致如果队首的请求耗时过长，后面的请求就只能处于阻塞状态，这就是著名的队头阻塞问题。解决如下：

并发连接

因为一个域名允许分配多个长连接，就相当于增加了任务队列，不至于一个队列里的任务阻塞了其他全部任务。以前在RFC2616中规定过客户端最多只能并发2个连接，但是现实是很多浏览器不按套路出牌，并没有遵守这个标准，所以在RFC7230把这个规定取消掉了。现在的浏览器标准中一个域名并发连接可以有6-8个(Chrome6个/Firefox8个)。

域名分片

一个域名最多可以并发6~8个，那咱就多来几个域名。

比如a.baidu.com，b.baidu.com，c.baidu.com，多准备几个二级域名，当我们访问baidu.com时，可以让不同的资源从不同的二域名中获取，而它们都指向同一台服务器，这样能够并发更多的长连接了

而在HTTP2.0下，可以一瞬间加载出来很多资源，因为支持多路复用，可以在一个TCP连接中发送多个请求。

1.2.9 HTTP 代理

常见的代理有两种：普通代理(中间人代理)，隧道代理

1.2.9.1 普通代理(中间人代理)

代理服务器相当于一个中间人，一直帮两边传递东西，不过它可以在中间可以帮我们过滤、缓存、负载均衡(多台服务器共用一台代理情况下)等一些处理。

注意，实际场景中客户端和服务器之间可能有多个代理服务器。

1.2.9.2 隧道代理

客户端通过CONNECT方法请求隧道代理创建一个可以到任意目标服务器和端口号的TCP连接，创建成功之后隧道代理只做请求和响应数据的转发，中间它不会做任何处理。

为什么需要隧道代理呢？

我们都知道https服务是需要网站有证书的，而代理服务器显然没有，所以浏览器和代理之间无法创建TLS，所以就有了隧道代理。它把浏览器的数据原样透传，这样就实现了通过中间代理和服务端进行TLS握手，然后进行加密传输

可能有人会问，那还要代理干嘛，直接请求服务器不是更好吗？

1.2.9.3 代理服务器，到底有什么好处呢？

突破访问限制：如访问一些单位或集团内部资源，或用国外代理服务器(翻墙)，就可以上国外网站看片等。
安全性更高：上网者可以通过这种方式隐藏自己的IP，免受攻击。还可以对数据过滤，对非法IP限流等。
负载均衡：客户端请求先到代理服务器，而代理服务器后面有多少源服务器，IP是多少，客户端是不知道的。因此，代理服务器收到请求后，通过特定的算法(随机算法、轮询、一致性hash、LUR(最近最少使用) )把请求分发给不同的源服务器，让各个源服务器负载尽量均衡。
缓存代理：将内容缓存到代理服务器。

1.2.9.4 代理最常见的请求头

Via

是一个能用首部，由代理服务器添加，适用于正向和反向代理，在请求和响应首部均可出现，这个消息首部可以用来追踪消息转发情况，防止循环请求，还可以识别在请求或响应传递链中消息发送者对于协议的支持能力

Via: 1.1 vegur

Via: HTTP/1.1 GWA

Via: 1.0 fred, 1.1 p.example.net

X-Forwarded-For

记录客户端请求的来源IP，每经过一级代理(匿名代理除外)，代理服务器都会把这次请求的来源IP追加进去

X-Forwarded-For: client,proxy1,proxy2

注意：与服务器直连的代理服务器的IP不会被追加进去，该代理可通过TCP连接的Remote Address字段获取到与服务器直连的代理服务器IP。

X-Real-IP

一般记录真实发出请求的客户端的IP，还有X-Forwarded-Host和X-Forwarded-Proto分别记录真实发出请求的客户端的域名和协议名。

1.2.9.5 代理中客户端IP伪造问题以及如何预防？

X-Forwarded-For是可以伪造的，比如一些通过X-Forwarded-For获取到客户端IP来限制刷票的系统就可以通过伪造该请求头达到刷票的目的，如果客户端请求显示指定了：

X-Forwarded-For：192.168.1.108

那么服务端收到的这个请求头，第一个IP就是伪造的。

预防：

1.在对外Nginx服务器上配置

location {
    proxy_set_header X-Forwarded-For $remote_addr
}

这样第一个IP就是从TCP连接客户端的IP，不会读取伪造的。

2.从右到左遍历X-Forwarded-For的IP，排除已知代理服务器IP和内网IP，获取到第一个符合条件的IP就可以了。

1.2.9.6 正向代理和反向代理

1.2.9.6.1 正向代理

工作在客户端的代理为正向代理。使用正向代理的时候，需要在客户端配置需要使用的代理服务器，正向代理对服务端透明。比如抓包工具Fiddler、Charles以及访问一些外网网站的代理工具都是正向代理。

正向代理通常用于

缓存
屏蔽某些不健康的网站
通过代理访问原本无法访问的网站
上网认证，对用户访问进行授权

1.2.9.6.2 反向代理

工作在服务端的代理称为反向代理。使用反向代理的时候，不需要在客户端进行设置，反向代理对客户端透明。如Nginx就是反向代理。

反向代理通常用于：负载均衡、服务端缓存、流量隔离、日志、金丝雀发布。

1.2.9.7 代理中的长连接

在各个代理和服务器、客户端节点之间是一段一段的TCP连接，客户端通过代理访问目标服务器也叫逐段传输，用于逐段传输的请求头叫逐段传输头。

逐段传输头会在每一段传输的中间代理中处理掉，不会传给下一个代理。

标准的逐段传输头有：Keep-Alive、Transfer-Encoding、TE、Connection、Trailer、Upgrade、Proxy-Authorization、Proxy-Authenticate。

Connection头决定当前事务完成后是否关闭连接，如果该值为keep-alive，则连接是持久连接不会关闭，使得对同一服务器的请求可以继续在该连接上完成。

1.2.10 HTTP 版本

1991年HTTP 0.9版，只有一个GET，而且只支持纯文本内容，早已过时就不讲了。

1.2.10.1 HTTP 1.0(1996年)

任意数据类型都可以发送
有GET、POST、HEAD三种方法
引入长连接，只是默认关闭
有丰富的请求响应头信息。以header中的Last-Modified/If-Modified-Since和Expires作为缓存标识

1.2.10.2 HTTP 1.1(1997年)

引入更多的请求方法类型PUT、PATCH、DELETE、OPTIONS、TRACE、CONNECT
长连接默认开启，可以被多个请求复用，通过请求头connection:keep-alive设置
引入管道连接机制，可以在同一TCP连接里，同时发送多个请求
强化了缓存管理和控制 Cache-Control、ETag/If-None-Match
支持分块响应，断点续传，利于大文件传输，通过请求头中的Range实现
使用了虚拟网络，在一台物理服务器上可以存在多个虚拟主机，并且共享一个IP地址

缺点：主要是连接缓慢，服务器只能按顺序响应，如果某个请求花了很长时间，就会出现请求队头阻塞。

虽然出了很多优化技巧：为了增加并发请求，做域名拆分、资源合并、精灵图、资源预取...等等，最终为了推进从协议上进行优化，Google跳出来，推出SPDY协议。

1.2.10.3 SPDY(2009年)

SPDY（读作“SPeeDY”）是Google开发的基于TCP的会话层协议

主要通过帧、多路复用、请求优先级、HTTP报头压缩、服务器推送以最小化网络延迟，提升网络速度，优化用户的网络使用体验

原理是在SSL层上增加一个SPDY会话层，以在一个TCP连接中实现并发流。通常的HTTP GET和POST格式仍然是一样的，然而SPDY为编码和传输数据设计了一个新的帧格式。因为流是双向的，所以可以在客户端和服务端启动

虽然诞生后很快被所有主流浏览器所采用，并且服务器和代理也提供了支持，但是SPDY核心人员后来都参加到HTTP 2.0开发中去了，自HTTP2.0开发完成就不再支持SPDY协议了，并在Chrome 51中删掉了SPDY的支持。

缺点：

TCP以及TCP+TLS建立连接的延时，HTTP2使用TCP协议来传输的，而如果使用HTTPS的话，还需要TLS协议进行安全传输，而使用TLS也需要一个握手过程，在传输数据之前，导致我们花掉3~4个RTT
TCP的队头阻塞并没有彻底解决。在HTTP2中，多个请求跑在一个TCP管道中，但当HTTP2出现丢包时，整个TCP都要开始等待重传，那么就会阻塞该TCP连接中的所有请求

1.2.10.4 HTTP 2.0(2015年)

使用新的二进制协议，不再是纯文本，避免文本歧义，缩小了请求体积
多路复用，同域名下所有通信都是在单链接(双向数据流)完成，提高连接的复用率，在拥塞控制方面有更好的能力提升
使用HPACK算法将头部压缩，用哈夫曼编码建立索表，传送索引大大节约了带宽
允许服务端主动推送数据给客户端
增加了安全性，使用HTTP 2.0，要求必须至少TLS 1.2
使用虚拟的流传输消息，解决了应用层的队头阻塞问题

1.2.10.5 SPDY 和 HTTP2 的区别

头部压缩算法，SPDY是通用的deflate算法，HTTP2是专门为压缩头部设计的HPACK算法
SPDY必须在TLS上运行，HTTP2可在TCP上直接使用，因为增加了HTTP1.1的Upgrade机制
SPDY更加完善的协议商讨和确认流程
SPDY更加完善的Server Push流程
SPDY增加控制帧的种类，并对帧的格式考虑的更细致

1.2.10.6 HTTP1 和 HTTP2

HTTP2是一个二进制协议，HTTP1是超文本协议，传输的内容都不是一样的
HTTP2报头压缩，可以使用HPACK进行头部压缩，HTTP1则不论什么请求都会发送
HTTP2服务端推送(Server push)，允许服务器预先将网页所需要的资源push到浏览器的内存当中
HTTP2遵循多路复用，代替同一域名下的内容，只建立一次连接，HTTP1.x不是，对域名有6~8个连接限制
HTTP2引入二进制数据帧和流的概念，其中帧对数据进行顺序标识，这样浏览器收到数据之后，就可以按照序列对数据进行合并，而不会出现合并后数据错乱的情况，同样是因为有了序列，服务器就可以并行的传输数据，这就是流所做的事情。HTTP2对同一域名下所有请求都是基于流的，也就是说同一域名下不管访问多少文件，只建立一次连接

1.2.10.7 HTTP 3.0(QUIC)

由于HTTP 2.0依赖于TCP，TCP有什么问题那HTTP2就会有什么问题。最主要的还是队头阻塞，在应用层的问题解决了，可是在TCP协议层的队头阻塞还没有解决。

TCP在丢包的时候会进行重传，前面有一个包没收到，就只能把后面的包放到缓冲区，应用层是无法取数据的，也就是说HTTP2的多路复用并行性对于TCP的丢失恢复机制不管用，因此丢失或重新排序的数据都会导致交互挂掉。

为了解决这个问题，Google又发明了QUIC协议，并在2018年11月将QUIC正式改名为HTTP 3.0。

特点：

在传输层直接干掉TCP，用UDP替代
实现了一套新的拥塞控制算法，彻底解决TCP中队头阻塞的问题
实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性
实现了快速握手功能。由于QUIC是基于UDP的，所以QUIC可以实现使用0-RTT或者1-RTT来建立连接，这意味着QUIC可以用最快的速度来发送和接收数据。
集成了TLS加密功能。目前QUIC使用的是TLS1.3

1.2.11 HTTP 和 HTTPS 的区别

HTTP是明文传输，不安全的，HTTPS是加密传输，安全的多
HTTP标准端口是80，HTTPS标准端口是443
HTTP不用认证，免费；HTTPS需要认证，证书要钱
连接方式不同，HTTP三次握手，HTTPS中TLS1.2版本7次，TLS1.3版本6次
HTTP在OSI网络模型中是在应用层，而HTTPS的TLS是在传输层
HTTP是无状态的，HTTPS是有状态的

1.3 在浏览器中输入url地址 -> 显示主页的过程

1.4 IP地址（IPv4地址）

1.4.1 定义

是连接在Internet中的每一台主机（或路由器）的全球唯一的标识符。

1.4.2 组成

IP地址 = 32位 = 网络号 + 主机号；即IP地址::={<网络号>，<主机号>}，其中：

网络号：标志主机（或路由器）所连接到的网络。一个网络号在整个因特网范围内必须是唯一的。
主机号：标志该主机（或路由器）。一个主机号在它面前的网络号所指明的网络范围必须是唯一的。

不同类型的IP地址，其主机号 & 网络号所占字节数不同；故：一个IP地址在整个网络范围内是唯一的。

1.4.3 分类

传统的IP地址是分类的地址，分为A，B，C，D，E五类，区别在于网络号 & 主机号占的字节数不同。

特别注意：在各类IP地址中，有一些IP地址用于特殊用途，不能用于做主机IP地址：

1.5 ICMP协议

1.5.1 定义

Internet Control Message Protocol，即网际控制报文协议。

属于IP层协议
注：ICMP报文不是高层协议，而是作为IP层数据报的数据，加上数据报首部，组成IP数据报发出去

1.5.2 作用

更有效地转发IP数据包 & 提高交付成功的机会，同时允许主机 / 路由器报告差错 & 异常情况。

1.5.3 分类

ICMP差错报告报文 & ICMP询问报文

1.5.4 主要应用

PING（分组网间探测）、Traceroute（跟踪1个分组从源点到终点的路径，原理 = 从源主机向目的主机发送一连串的IP数据报）.

1.6 Ping的过程

1.6.1 定义

Packet InterNet Groper，即分组网间探测。

是 ICMP报文的1个重要应用：使用了IPCM回送请求 & 回送回答报文。

是应用层直接使用网络层ICMP的1个例子，不经过传输层的TCP、UDP。

1.6.2 作用

测试2个主机的连通性

1.6.3 原理

向目的主机发送多个ICMP回送请求报文
根据目的主机返回的ICMP回送回答报文中的时间戳，从而计算出往返时间
最终显示的结果：发送到目的主机的IP地址、发送 & 收到 & 丢失的分组数、往返时间的最小、最大 & 平均值

1.6.4 过程

假设有两台主机：

（目的主机）PC1：IP = 192.168.1.1

（源主机）PC2：IP = 192.168.1.2

HTTP 攻略