【全网最全】面试高频知识点汇总 网络协议专题 （持续更新）

2022-05-10 09:09:19 浏览数 (1)

本博文基本覆盖互联网公司关于网络协议的所有知识点，只要这里面的协议、算法、特性都好好记住，面试中的网络协议环节基本能够对答如流。

本博文所有内容均在面试中出现过，没有多余信息。

OSI七层、五层体系结构以及各层对应的网路协议

OSI分层(7层)：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。

TCP/IP分层(4层)：网络接口层、网际层、运输层、应用层。

五层协议：物理层、数据链路层、网络层、运输层、应用层。

每一层对应的协议如下：

  • 物理层：RJ45(网线)、CLOCK、IEEE802.3(中继器，集线器)
  • 数据链路层：PPP、FR、HDLC、VLAC、MAC(网桥，交换机)
  • 网络层：IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP、EIGRP(路由器)
  • 传输层：TCP、UDP、SPX
  • 会话层：NFS、SQL、NETBIOS、RPC
  • 表示层：JPEG、MPEG、ASCII
  • 应用层：FTP、DNS、Telnet、SMTP、POP3、IMAP、HTTP、WWW、NFS

注：交换机位于数据链路层，路由器位于网络层。

每一层的作用：

  • 物理层：通过媒介传输比特,确定机械及电气规范(比特Bit)
  • 数据链路层：将比特组装成帧和点到点的传递(帧Frame)
  • 网络层：负责数据包从源到宿的传递和网际互连(包Packet)
  • 传输层：提供端到端的可靠报文传递和错误恢复(段Segment)
  • 会话层：建立、管理和终止会话(会话协议数据单元SPDU)
  • 表示层：对数据进行翻译、加密和压缩(表示协议数据单元PPDU)
  • 应用层：允许访问OSI环境的手段(应用协议数据单元APDU)

ICMP协议

ICMP(Internet Control Message Protocol)协议，即Internet控制报文协议。它是TCP/IP协议簇的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。这些控制消息虽然并不传输用户数据，但是对于用户数据的传递起着重要的作用。

  • ping命令(Win、Unix兼有)基于ICMP协议，用于测试网络通信情况。
  • traceroute(Unix)、tracert(Win)基于ICMP协议，追踪路由路径。

Windows ping：

代码语言：javascript复制
Microsoft Windows [版本 10.0.18362.900]
(c) 2019 Microsoft Corporation。保留所有权利。

C:Userswangh>ping www.baidu.com

正在 Ping www.a.shifen.com [182.61.200.6] 具有 32 字节的数据:
来自 182.61.200.6 的回复: 字节=32 时间=31ms TTL=44
来自 182.61.200.6 的回复: 字节=32 时间=32ms TTL=44
来自 182.61.200.6 的回复: 字节=32 时间=28ms TTL=44
来自 182.61.200.6 的回复: 字节=32 时间=29ms TTL=44

182.61.200.6 的 Ping 统计信息:
    数据包: 已发送 = 4，已接收 = 4，丢失 = 0 (0% 丢失)，
往返行程的估计时间(以毫秒为单位):
    最短 = 28ms，最长 = 32ms，平均 = 30ms

Windows tracert

代码语言：javascript复制
C:Userswangh>tracert www.baidu.com

通过最多 30 个跃点跟踪
到 www.a.shifen.com [182.61.200.6] 的路由:

  1     2 ms     1 ms    <1 毫秒 192.168.1.1
  2    13 ms    12 ms    24 ms  59.78.194.1
  3     2 ms     2 ms     1 ms  10.100.120.1
  4     3 ms    28 ms     6 ms  202.120.95.226
  5     3 ms     2 ms     2 ms  202.120.95.254
  6    18 ms    27 ms    27 ms  10.255.16.1
  7     4 ms    17 ms    12 ms  10.255.249.253
  8     3 ms     2 ms     2 ms  10.255.38.254
  9     3 ms     3 ms     9 ms  202.112.27.1
 10    10 ms     8 ms     7 ms  101.4.115.105
 11   101 ms    22 ms    22 ms  101.4.117.30
 12    32 ms    54 ms    48 ms  101.4.116.118
 13    28 ms    30 ms    29 ms  101.4.112.69
 14    43 ms    41 ms    72 ms  219.224.103.38
 15    63 ms    69 ms    57 ms  101.4.130.38
 16    49 ms    72 ms    37 ms  182.61.255.32
 17     *       31 ms    31 ms  182.61.255.45
 18     *        *        *     请求超时。
 19     *        *        *     请求超时。
 20     *        *        *     请求超时。
 21    29 ms    34 ms    31 ms  182.61.200.6

跟踪完成。

Ubuntu ping：

代码语言：javascript复制
steve@steve:~$ ping www.baidu.com -c 5
PING www.a.shifen.com (182.61.200.6) 56(84) bytes of data.
64 bytes from 182.61.200.6: icmp_seq=1 ttl=44 time=29.9 ms
64 bytes from 182.61.200.6: icmp_seq=2 ttl=44 time=30.8 ms
64 bytes from 182.61.200.6: icmp_seq=3 ttl=44 time=31.0 ms
64 bytes from 182.61.200.6: icmp_seq=4 ttl=44 time=31.0 ms
64 bytes from 182.61.200.6: icmp_seq=5 ttl=44 time=31.1 ms

--- www.a.shifen.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 29.927/30.797/31.119/0.455 ms

Ubuntu下的ping指明了使用ICMP协议，过程中有icmp_seq，即icmp_序列号。

Ubuntu traceroute

代码语言：javascript复制
steve@steve:~$ traceroute www.baidu.com
traceroute to www.baidu.com (182.61.200.6), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  1.589 ms  3.941 ms  8.143 ms
 2  59.78.194.1 (59.78.194.1)  44.159 ms  44.641 ms  44.782 ms
 3  10.100.120.1 (10.100.120.1)  44.920 ms  45.046 ms  45.182 ms
 4  202.120.95.226 (202.120.95.226)  45.355 ms  45.491 ms  45.642 ms
 5  202.120.95.254 (202.120.95.254)  46.064 ms  46.206 ms  46.339 ms
 6  10.255.16.1 (10.255.16.1)  46.721 ms  2.502 ms  2.763 ms
 7  10.255.249.253 (10.255.249.253)  3.370 ms  3.736 ms  3.888 ms
 8  10.255.38.254 (10.255.38.254)  4.078 ms  4.991 ms  5.415 ms
 9  202.112.27.1 (202.112.27.1)  8.243 ms  8.379 ms  8.512 ms
10  101.4.115.105 (101.4.115.105)  5.502 ms  6.001 ms  6.751 ms
11  101.4.117.30 (101.4.117.30)  26.087 ms  26.196 ms  26.281 ms
12  * 101.4.116.118 (101.4.116.118)  26.735 ms  28.027 ms
13  101.4.112.69 (101.4.112.69)  30.100 ms  30.475 ms  31.273 ms
14  219.224.103.38 (219.224.103.38)  32.299 ms  32.602 ms  32.731 ms
15  101.4.130.38 (101.4.130.38)  33.548 ms 101.4.130.34 (101.4.130.34)  35.711 ms 101.4.130.38 (101.4.130.38)  33.663 ms
16  182.61.255.0 (182.61.255.0)  33.790 ms 182.61.255.2 (182.61.255.2)  29.172 ms 182.61.255.28 (182.61.255.28)  29.144 ms
17  182.61.255.51 (182.61.255.51)  45.775 ms 182.61.255.45 (182.61.255.45)  133.638 ms  133.732 ms
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

TCP、UDP协议的区别

类型

面向连接

传输可靠性

传输形式

传输效率

所需资源

应用场景

首部字节

TCP

面向连接

可靠

字节流

慢

多

要求通讯数据可靠(文件传输、邮件传输)

20-60

UDP

无连接

不可靠

数据报文段

快

少

要求通信速度快(域名转换)

8个字节

TCP提供面向连接的服务。数据传送之前必须先建立连接，数据传送结束后要释放连接。TCP不提供广播或者多播服务。

TCP的可靠性体现在传递数据之前，会有三次握手来建立连接，数据传递时，有确认、窗口、重传、拥塞控制机制，数据传送完毕后，还会有四次挥手断开链接。

UDO报文的最大长度为512字节，而TCP则允许长度超过512字节。当DNS查询超过512字节时，协议的TC标志出现删除标志，这是则使用TCP标志。通常UDP的报文不会大于512字节。

补充：DNS协议和TCP/UDP协议的关系

DNS同时占用UDP和TCP端口53，这种单个应用协议同时使用两种传输协议的情况在TCP/IP栈中也算另类。

DNS在进行区域传输(zone transfer)的时候使用TCP协议，其他时候使用UDP协议。

注： 辅域名服务器定时（一般3小时）向主域名服务器进行查询以便了解数据是否有变动。如有变动则执行一次区域传送，进行数据同步。区域传送将使用TCP而不是UDP，因为数据同步传送的数据量比一个请求和应答的数据量要多得多。

三次握手四次挥手

  • TCP的三次握手过程，为什么采用三次握手，若采用二次握手可以吗？

失效的连接请求的特殊情况： 采用三次握手是为了防止失效的连接请求报文段突然又传送到主机B，因而产生错误。考虑这样一种特殊情况，主机A第一次发送的连接请求并没有丢失，而是因为网络节点导致延迟达到主机B，主机B以为是主机A又发起的新连接，于是主机B同意连接，并向主机A发送确认，但是此时主机A根本不会理会，主机B就一直在等待主机A发送数据，导致主机B的资源浪费。

  • SYN Flood攻击是什么原因？

三次握手的缺陷：

第二次握手时候会出现：SYN Timeout.

典型的Dos式攻击，向服务器发送大量的连接请求，在收到服务端的SYN报文后不作出任何响应，导致服务器开启了大量半连接资源耗尽。这时候如果有正常的客户端向服务发出第一次握手请求建立连接，会出现SYN Timeout的错误，因为服务器无法响应。

  • 为什么释放连接的时候是四次挥手，比建立连接时的三次多了一次？

对比三次挥手和四次握手的过程，四次挥手多了一次的原因在于，客户端需要服务器发送两个确认报文，对应两个FIN-WAIT状态。这样设计的原因是：客户端需要等待服务器一段时间，服务器有可能在这段时间再发送一些数据。

  • 四次挥手释放连接时，等待2MSL的意义。

(1) 为了保证客户端发送的最后一个ACK报文段能够到达服务器。因为这个ACK有可能丢失，从而导致处在LAST-ACK状态的服务器收不到对FIN-ACK的确认报文。服务器会超时重传这个FIN-ACK，接着客户端再重传一次确认，重新启动时间等待计时器。最后客户端和服务器都能正常的关闭。假设客户端不等待2MSL(Maxumum Segment Lifetime)，而是在发送完ACK之后直接释放关闭，一但这个ACK丢失的话，服务器就无法正常的进入关闭连接状态。 (2) 等待已失效的报文段从网络中消失。客户端在发送最后一个ACK之后，再经过经过2MSL，就可以使本链接持续时间内所产生的所有报文段都从网络中消失。从保证在关闭连接后不会有还在网络中滞留的报文段去骚扰服务器。

  • 出现大量的CLOSE_WAIT

服务器忙于读写，无法及时发送FIN-ACK报文。

TCP协议如何保证可靠传输 (重点)

  1. 应用数据被分割成TCP最适合发送的数据块。
  2. TCP给发送的每一个包进行编号，接收方对数据包进行排序，将有序数据传送给应用层。
  3. 校验和：TCP将保持它首部和数据的校验和。这是一个端到端的检验和，目的时检测数据在传输过程中的任何变化。如果校验和有差错，TCP将丢弃这个报文段并不确认收到此报文。
  4. TCP的接收端会丢弃重复的数据。
  5. 流量控制：TCP连接的每一方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP使用的流量控制协议是可变大小的滑动窗口协议。
  6. 拥塞控制：当网络拥塞时，减少数据的发送。
  7. 停止等待协议：也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段(超时重传)。
ARQ协议

⾃动重传请求（Automatic Repeat-reQuest，ARQ）是OSI模型中数据链路层和传输层的错误纠正协议之⼀。它通过使⽤确认和超时重传这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送⽅在发送后⼀段时间之内没有收到确认帧，它通常会重新发送。

ARQ包括停止等待ARQ协议和连续ARQ协议。

停止等待ARQ协议：基本原理时每发完一个分组就停止发送，等待对方确认。收到确认后再发下一个分组。

连续ARQ协议：指发送方维持着一个一定大小的发送窗口，位于发送窗口内的所有分组都可连续发送出去，而中途不需要等待对方的确认。这样信道的利用率就提高了。而发送方每收到一个确认就把发送窗口向前滑动一个分组的位置。 接收方一般都是采用积累确认的方式。这就是说，接收方不必对收到的分组逐个发送确认，而是在收到几个分组后，对按序到达的最后一个分组发送确认，这就表示：到这个分组为止的所有分组都已正确收到了。

拥塞控制包括四部分：慢启动、拥塞避免，快速重传、快速恢复。

发送端向网络一次连续写入的数据量，记为SWND(Send Window，发送窗口)。由于发送端最终以TCP报文段来发送数据。这些TCP报文段的最大长度(仅数据部分)称为SMSS(Sender Maximum Segment Size，发送端最大段大小)，其值一般等于MSS。

发送端需要选择合适大小的SWND，如果SWND太小，会引起明显的网络延迟；反之，如果SWND太大，则容易导致网络拥塞。所以还需要引入一个拥塞窗口(Congestion Window，CWND)的状态变量。

慢启动： 发送方维持一个拥塞窗口CWND的状态变量。它的大小取决于网络的拥塞程度，并且在动态变化，发送方会让自己的发送窗口等于这个拥塞窗口。

发送方控制拥塞窗口的原则是： (1) 只要网络没有出现拥塞，拥塞窗口就再增大一些，以便把更多的分组发送出去； (2) 但只要网络出现拥塞，拥塞窗口就减小一些，以减小注入到网络中的分组数。

慢启动算法：由于不清楚网络状况，所以需要进行试探，将发送窗口逐渐增大，也即逐渐增大拥塞窗口的数值。在刚开始发送的时候，先把拥塞窗口CWND设置为最大报文段MSS，每收到一个对新报文段的确认后，就把拥塞窗口最多增加一个MSS数值。这种逐步增大的方法可以使分组注入到网络的速率更加合理【指数增长】。

为了防止拥塞窗口过大引起网络拥塞，我们需要设置一个慢开始门限ssthreth状态变量。当CWND<ssthreth时，使用慢开始算法；当CWND>ssthreth时，使用拥塞控制算法；如果两者相等，慢开始和拥塞控制都可以使用。

慢启动的“慢”并不是指CWND增长速率慢而是说在TCP开始发送报文时，先设置CWND=1，使发送端开始时只发送一个报文段进行探测。

拥塞避免：就是让拥塞窗口缓慢增大，即每经过一个往返时间RTT就使CWND 1，这种线性增长的速率慢很多。

只要发送方判断出网络拥塞，不论在慢开始还是拥塞控制阶段，都要把慢开始门限值设置为出现拥塞时发送窗口大小的一半，但不能小于2，然后CWND重新设置为1，执行慢开始算法。

门限值减半，CWND重置为1，目的是减少发送到网络中的分组数，使得发生拥塞的路由器能够有时间把队列中积压的分组处理掉。

发送端判断网络拥塞的依据： (1) 传送超时，即TCP重传定时器溢出。 (2) 收到重复的确认报文。

快重传：快重传算法要求接收方每收到一个失序的报文段之后就立即发出重复确认，而不要等到自己发送数据才进行捎带确认。发送方只要收到3个同样的确认报文段就应当立即重传数据报，不必等到报文段的重传计时器到期。

快恢复：把慢开始门限减半，“乘法减小”，将CWND设置为新的慢开始门限值，继续执行拥塞避免算法，加法增大。

TCP滑动窗口和拥塞窗口

相同点：提高网络性能。 不同：

  • 流量控制(滑动窗口，接收端)：在TCP连接上实现对发送流量的控制，考虑点对点之间对通信量的控制，是端对端的问题。即：控制发送端的数据发送速率，使得接收端来得及接收，保证网络高效稳定运行。
  • 拥塞控制(拥塞窗口，发送端)：处理网络拥塞现象，考虑网络能够承受现有的负荷，全局性变量，涉及所有的路由器、主机以及降低网络传输性能有关的因素。防止过多的数据注入到网络，使网络中的路由器或者链路不致过载，确保子网可以有效为主机传递分组。

在浏览器输入一个url地址到显示页面的过程

  1. 浏览器查找域名的IP地址(DNS查找过程、浏览器缓存、路由器缓存、DNS缓存)。【对应DNS协议:获取域名对应IP，DNS查找过程，在下面，要详细叙述出来】
  2. 浏览器作为客户端向服务器发起TCP连接，连接建立后向web服务器发送一个HTTP请求(该过程中cookies会随着请求发送给服务器)。
  3. 服务器处理请求(请求、处理请求及其参数、cookies，生成一个HTML响应)。
  4. 服务器返回一个HTML响应。
  5. 浏览器开始显示HTML。

2-5 包含协议： IP：建立TCP协议时，需要发送数据，在网络层使用IP协议 ARP：路由器在与服务器通信时，需要将IP地址转化为MAC地址，该过程使用ARP协议 OSPF：IP数据包在路由器之间，路由器选择使用OSPF协议(类似协议有RIP协议、IGRP(cisco私有)、EIGRP(cisco私有) TCP：与服务器建立连接 HTTP：TCP连接建立完成后，使用HTTP协议访问网页

  1. DNS解析
  2. TCP连接
  3. 发送HTTP请求
  4. 服务器处理请求并返回HTTP报文
  5. 浏览器解析渲染画面
  6. 连接结束

DNS查找过程

浏览器缓存→ rightarrow→系统缓存→ rightarrow→路由器缓存→ rightarrow→ISP DNS缓存→ rightarrow→递归搜索

先从缓存里面找，找不到借助域名服务器执行递归搜索。

执行递归搜索时，先向本地域名服务器进行递归查询，如果没有，则从根域名服务器开始，按域名层级依次查找。

状态码

有些公司会问的很细，比如505是什么意思？

状态码

类别

原因短语

1xx

Information(信息性状态码)

接收的请求正在处理

2xx

Success(成功状态码)

请求正常处理完毕

3xx

Redirection(重定向状态码)

需要附加操作以完成请求

4xx

Clien Error(客户端错误状态码)

服务器无法处理请求

5xx

Server Error(服务器错误状态码)

服务器处理请求出错

全部状态码列表参见这里。

这里只列举面试常考的，但请注意，面试官非常也有可能问特别偏的，500开头的，即服务端错误要求全部记住。

状态码

英文名称

中文解释

100

Continue

继续，客户端继续其请求。

200

OK

请求成功。

301

Moved Permanently

请求的资源已被永久移动到新的URI。

307

Temporary Redirect

临时重定向。

401

Unauthorized

进行的请求要求用户进行认证，未取得授权。

403

Forbidden

拒绝执行请求。

404

Not Found

请求的资源未找到。

500

Internal Server Error

服务器内部错误。

501

Not implement

当前所请求的功能还未实现。

502

Bad Gateway

网关或者代理服务器从远程服务器接收到了一个无效响应。

503

Service Unavailable

由于超载或者维护，服务器暂时无法处理请求。

504

Gateway Time-out

网关或者代理服务器接收远程服务器响应超时

505

HTTP Version not supported

服务器不支持请求的HTTP版本

HTTP是不保存状态的协议，如何保存用户状态？

使用Session和Cookies。

Session和Cookies的区别

Cookies和Session都是用来跟踪浏览器用户身份的会话方式，应用场景不太一样。

Cookies一般用来保存用户信息: (1)保存上次登录信息，下次自动填充； (2)下次访问不需要重新登陆； (3)登录一次网站后访问同网站其他页面不需要重新登录。

Session主要作用通过服务端记录用户的状态(典型场景购物车)。

Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。 Cookie 存储在客户端中，⽽Session存储在服务器上，相对来说 Session 安全性更⾼。如果要在Cookie 中存储⼀些敏感信息，不要直接写⼊ Cookie 中，最好能将 Cookie 信息加密然后使⽤到的时候再去服务器端解密。

HTTP1.0和HTTP1.1的主要区别

  1. 长连接：HTTP/1.0使用短链接，每次请求都要建立一次连接；HTTP/1.1使用长连接，默认开启Conection: keep-alive。持续连接分为流水线方式和非流水线方式。流水线是指，客户端在收到HTTP响应报文前就能接着发送新的请求报文；非流水线则是指客户端收到响应之后才能发送下一个请求。
  2. HTTP/1.1新增了24个错误状态响应码。如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
  3. 缓存处理：HTTP/1.1新增了更多的缓存头来控制缓存控制策略。
  4. 带宽优化及网络连接的使用：HTTP/1.1允许只请求资源的某个部分，以此节省带宽。
使用了长链接之后，client、server怎么知道本次传输结束呢？

推断数据传输是否达到了Content-Length仅仅是判断大小。动态生成的文件没有Content-Length，它是分块传输(chunked)。分块传输的数据最后会是一个空的chunked块，表示本次传输的结束。

长链接的过期时间： client的长链接不可能无限期的维持，有下面两种关闭长链接的方式：

  1. server会告诉client超时时间。在响应头部中Keep-Alive指明timeout时间或者max最大事务数。
  2. cilent或者服务器断开连接(关闭或者下线)，主动发起四次挥手。

HTTP1.1和HTTP2.0的主要区别

  • (多路复用) HTTP2.0使用了多路复用的技术，做到同一个连接并发处理多个请求，而且并发请求的数量比HTTP 1.0大了好几个数量级。HTTP 1.1也可以建立多个TCP连接，来支持处理更多并发的请求，但是创建TCP连接本身也是有开销的。
  • (header数据压缩) HTTP1.1不支持header数据的压缩，HTTP2.0使用HPACK算法对header的数据进行压缩，这样数据体积变小了，在网络上传输就会更快。
  • (服务器推送) 当我们对支持HTTP 2.0的web server请求数据的时候，服务器会顺便把一些客户端需要的资源一起推送到客户端，这样可以避免客户端再次创建连接发送请求到服务器端获取。这种方式非常适合加载静态资源。

服务器端推送的这些资源其实存在客户端的某处地方，客户端直接从本地加载这些资源就可以，不需要走网络，速度自然会快很多。

如果HTTP连接建立的时间比较长，该如何优化?

  • 并行连接(能够同时和多台server建立HTTP连接)
  • 持久连接
  • 管道化连接
  • 连接复用
并行连接

优点：能够在带宽资源充足的情况下同一时刻建立多个HTTP连接，加快页面的载入速度。

缺点：并行连接在带宽资源不足的情况下会使得连接竞争资源，效率反而下降。

同一时刻建立多条连接会大量消耗内存。

对server来说。大量的用户产生大量的连接可能会超过server的处理能力，因此server一般可以关闭来自特定client的超量连接。

持久连接(Keep-Alive/Persistent)

优点：重用已对目标server打开的空暇持久连接，就能够避免缓慢的连接建立阶段。同一时刻，已经打开的连接还能够避免慢启动的拥塞适应阶段，以便更快地进行数据传输， 如今的web应用程序都是并行连接 持久连接。

管道化连接

能够在持久连接上使用的可选的请求管道。相当于流水线的功能。在回应到达之前，能够将多条请求放入队列。

管道化连接的限制：

  • 假设连接不是持久的，就不应该使用管道
  • 必须依照与请求同样的顺序发送http响应。Http报文中没有序列号标签。因此假设收到的响应失序了。那么就没办法将其与请求匹配起来了。
  • http client必须做好连接会在任意时刻关闭的准备，还要准备重发全部未完毕的管道化请求。
  • http client不应用管道化的方式发送会产生副作用的请求(POST请求)。
连接复用

新的请求可以在上次建立的TCP连接上发送，连接可以复用。

优点：减少重复进行TCP三次握手的开销，提高效率。 注意：在同一个TCP连接中，新的请求需要等上次请求收到相应后，才能发送。

HTTP的请求方法

HTTP/1.1协议中一共定义了八种方法(有时也叫"动作")，来表明Request-URL指定的资源不同的操作方式。

HTTP1.0定义了三种请求方法：GET、POST和HEAD。

HTTP1.1新增了五种请求方法：OPTION、PUT、DELETE、TRACE和CONNECT方法。

方法

描述

GET

请求指定的页面信息，并返回实体主体

HEAD

类似于get请求，只不过返回的响应中没有具体的内容，用于获取报头

POST

向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。POST请求可能会导致新的资源建立和/或已有资源的修改。

PUT

从客户端向服务器传送的数据取代指定的文档的内容

DELETE

请求服务器删除指定的页面

CONNECT

HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

OPTIONS

允许客户端查看服务器的性能

TRACE

回显服务器收到的请求，主要用于测试或者诊断

HTTP报文格式

一个HTTP请求报文由请求行、请求头、空白行、请求体组成。

代码语言：javascript复制
<request-line>
<headers>
<blank line>
[<request-body>]

HTTP 响应报文由状态行、响应头部、空行和响应体 4 个部分组成。

代码语言：javascript复制
<status-line>
<headers>
<blank line>
[<response-body>]

HTTPS

HTTPS(Hypertext Transfer Protocol over Secure Socket Layer)，是以安全为目标的HTTP协议，即HTTP协议的安全版。HTTPS是在HTTP的基础上与SSL/TLS协议结合起来的一种协议，保证了传输过程中的安全性，减少了被恶意劫持的可能。很好的解决了解决了http的三个缺点（被监听、被篡改、被伪装）。

HTTP存在三大风险：

  1. 窃听风险（eavesdropping）：第三方可以获知通信内容。
  2. 篡改风险（tampering）：第三方可以修改通信内容。
  3. 冒充风险（pretending）：第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的，他可以：

  1. 内容加密：通信数据加密传播，来保证数据传输的安全，第三方无法窃听。
  2. 数据完整性：具有校验机制，一旦被篡改通信双方能立即发现。
  3. 身份验证：配备CA证书，确认网站的真实性，防止身份被冒充。

HTTP和HTTPS的区别

  1. 端口：HTTP使用80，HTTPS使用443。
  2. HTTPS协议需要到CA申请证书。
  3. 安全性和资源消耗：HTTP直接运行在TCP之上，所有传输的都是明文，客户端和服务器无法验证对方身份。HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，传输内容经过对称加密，但对称加密的密匙用服务器方的证书进行了非对称加密。
  • 对称加密：密匙只有一个，加密解密为同一个密匙；
  • 非对称加密：密匙成对出现(分为公匙和私钥，且根据公匙无法推知私钥，加密解密使用不同密匙)。
SSL/TLS协议到底工作在OSI模型中的那一层？

SSL/TLS协议位于TCP/IP协议与各种应用层之间，为数据通讯提供安全支持。

TCP/IP模型分四层：应用层，传输层，网络互联层，网络接口层。

SSL协议可以分为两层：

  • SSL记录协议 (SSL Record Protocol)：它建立在可靠传输协议(TCP)之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。
  • SSL握手协议(SSL Handshake)：它建立在记录协议之上，用于在实际传输开始前，通讯双方进行身份验证、协商加密算法、交换加密密匙等。

HTTPS连接的建立的详细过程

首先三次握手建立TCP连接，然后以以下步骤建立SSL/TLS连接

使用HTTPS之前需要确保服务端配置了对应的安全证书，握手阶段包含三次握手：

  1. 客户端生成一个随机数a，发送请求到服务端，包含随机数a，自己支持的加密协议，加密方法及版本，。
  2. 服务端从中筛选并确认使用的加密协议和加密方法，同时生成一个随机数b。如果版本无法一致，服务端将关闭加密通信；如果达成一致，服务端发送随机数b以及服务器证书，证书内含公匙，。
  3. 客户端使用根证书验证服务器发送证书的合法性；如果合法，客户端生成一个随机数c，使用证书中的公匙加密，发送给服务器端。
  4. 服务端收到加密的随机数后使用私钥解密得到真正的随机数c，随后以abc三个随机数作为参数使用加密算法需要发送的数据加密。

握手阶段完成，客户端与服务器进入加密通信，即完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

  1. 客户端在接收到加密后的数据以随机数abc作为参数使用协商好的加密算法，对数据进行解密并且解析数据并呈现。
  2. SSL加密连接建立。

HTTPS采用公开密匙加密(非对称加密)和共享密匙加密(对称加密)两者并用的混合加密。若密匙能够安全交换，那么有可能会考虑仅使用公开密匙加密来通信，但是这样的安全并不能保证。其次，公开密匙加密和共享密匙加密相比其处理速度要慢。

在该过程中，握手阶段客户端和服务端交换随机数c时，是非对称加密(客户端公匙加密该随机数，服务端私钥解密)，确保密匙无法被第三方获知。会话阶段，数据传输时加密使用的是对称加密(服务端和客户端都使用随机数私钥加密解密)。

HTTPS连接建立这样设计的理由是充分利用对称和非对称加密解密的优点，同时避开他们的缺点。在握手阶段，我们仅仅是要交换一下客户端生成的随机数，所以使用非对称加密保证绝对的安全；而在会话阶段我们要发送大量的数据，非对称加密代价很高，这个时候使用来对称加密提高加密速度。

  • 对称加密：密匙只有一个，加密解密为同一个密匙；
  • 非对称加密：密匙成对出现(分为公匙和私钥，且根据公匙无法推知私钥，加密解密使用不同密匙)。

常见的对称加密算法有DES、3DES、Blowfish、IDEA、RC4、RC6和AES。

常见的非对称加密算法有RSA、ECC、Diffie-Hellman、EI Gmaal、DSA。

浏览器加载网页的流程

  1. 浏览器载入HTML文件。
  2. 将HTML文件转化成一个DOM(Document Object Model)，DOM是文件在计算机内存中的表现形式。
  3. 拉取该HTML相关的大部分资源，比如嵌入到页面的图片、视频和CSS样式，JavaScript会在后面进行处理。
  4. 浏览器拉取到CSS之后会解析，然后根据选择器的不同类型(比如element、class、id等等)把它们分到不同的“桶”中。浏览器基于它找到的不同的选择器，将不同的规则(基于选择器的规则，如元素选择器、类选择器、id选择器等)应用在对用的DOM节点中，并添加节点依赖的样式(这个中间步骤称为渲染树)。
  5. 上述的规则应用于渲染树之后，渲染树会依照应该出现的结构进行布局。
  6. 网页展示在屏幕上(该步称为着色)。
  7. 在HTML和CSS集合组装成一个网页后，浏览器的JavaScript引擎将执行JavaScript代码。

参考

JavaGuide面试突击版，百度可得最新版本，有删改修正和扩充。

HTTP1.0 HTTP 1.1 HTTP 2.0主要区别

HTTP请求方式中8种请求方法（简单介绍）

HTTPS 建立连接的详细过程

SSL/TLS协议运行机制的概述

http连接优化

HTTPS原理和通信流程

SSL协议到底工作在OSI模型中的哪一层？

《图解HTTP》-上野宣(日)著

DNS查找域名的过程

DNS域名解析使用的是TCP协议还是UDP协议？

http tcp/ip javascript SSL证书

0 人点赞