计算机网络面试题

封装成帧：数据的封帧遵循以太网协议。以太网协议规定，一组电信号构成一个数据包，我们把这个数据包称之为帧。每一个桢由标头(Head)和数据(Data)两部分组成。MTU：最大传输单元；帧数据部分，受MTU限制大小<=1500字节【以太网标准】假如需要传送的数据很大的话，就分成多个桢来进行传送。

差错检验：因为物理层可能导致比特传输差错，数据链路层保证向上层（传输层）提供的数据是无差错的；常用的校验方法 CRC校验

透明传输：帧头帧尾出现在数据部分时，使用转义字符

物理层

将数据转化成电信号，让其可以在物理介质中传播；调制解调

OSI 的七层模型分别是？

将应用层分成：

会话层：负责建⽴、管理和终⽌表示层实体之间的通信会话

表示层：负责把数据转换成兼容另⼀个系统能识别的格式；

应用层：负责给应⽤程序提供统⼀的接⼝；

TCP连接的建立

三次握手

客户端向服务端发送连接请求；服务端向客户端发送确认请求；客户端向服务端发送确认的确认，同时带有应用数据； 连接建立

具体细节：客户端A 服务端B

客户端向服务端发送连接请求: A ->B 序号sqe = x；确认号 ack = 0；同步意向SYN = 1；确认号标志 ACK = 0;

服务端向客户端发送确认请求: B->A 序号 Sqe = y; 确认号 ack = x+1; 同步意向SYN = 1；确认号标志 ACK = 1;

客户端向服务端发送确认的确认: A - >B 序号 sqe = x+1；确认号 ack = y+1；同步意向 SYN = 0；确认号标志ACK = 1；

sqe：数据包序号

ack：确认收到数据，并提供准备接受下一个数据的序号

SYN：建立连接意向（发起连接时为 1，三次握手的前两次）

ACK：ack是否有效；

三次握手中客户端和服务端是什么状态

客户端A 服务端B

开始：A:closed; B:closed

客户端向服务端发送连接请求: A: SYN-sent; B: Listen

服务端向客户端发送确认请求: A: 收到之后 established B: 发送之后 SYN_recvd

客户端向服务端发送确认的确认: A:established B: 收到之后 established

为什么是三次，不是两次？

“第三次握手”是客户端向服务器端发送数据，这个数据就是要告诉服务器，客户端有没有收到服务器“第二次握手”时传过去的数据。

若发送的这个数据是“收到了”的信息，接收后服务器就正常建立TCP连接，否则建立TCP连接失败，服务器关闭连接端口。由此减少服务器开销和接收到失效请求发生的错误。

避免错误连接，造成服务器长时间等待

1.某个客户端发来的错误连接请求(比如由于超时被客户端丢弃的连接)，发送到服务端；2. 服务端发送确认请求；3.客户端收到请求之后会直接丢弃（任务是错误请求数据）4. 服务端则会任务，连接已经建立，持续等待--；

三次握手的话，3.中客户端根据历史信息，知道这是错误链接，可以直接向服务端发送一个rst报文，终止这次连接

同步双方的初始化序号

一来一回同步双方的序号，序号的作用: 数据去重，数据排序，数据校验等

四次可以不？

可以，但三次足够四次浪费了资源；

为什么客户端和服务端的初始化序号ISN不同

区分报文，根据序号将不属于本连接的报文丢弃；

什么是SYN攻击，如何解决？

伪造不同客户端IP 向服务端发送请求；使服务器长时间进入SYN-RCVD状态；

解决方法：

SYN泛洪攻击原理及预防策略详解

四次挥手流程

四次挥手中，主动分手的一方需要等待被分手的一方进行一定的准备工作；

大致流程：

第一次挥手：A 告诉 B ，‘’我要分手“；

第二次挥手：B回复A，“ 嗯，我知道了，我准备以下 ”

第三次挥手：B告诉A，‘’我准备好了可以分手了‘’

第四次挥手：A告诉B，‘’有缘再见‘’

等待一会儿，A拉黑了联系方式（A怕有缘再见的消息，B没有收到），B如果没有收到有缘再见会重新发送‘’我准备好了可以分手了‘’；

这里第二次挥手的准备是指 "当B把自己该发送的数据发送完成";

具体细节

客户端A 向服务端B发起释放连接请求

A—>B：序号seq = x，FIN=1
客户端A 停止发送数据，处于FIN_WAIT1状态
B—>A：序号seq = y，确认号ack = x+1，FIN=0；
服务端B收到 FIN报文之后，会发送一个 ack=x+1 的ACK报文，处于CLOSE_WAIT状态；
客户端A收到ACK报文之后，由FIN_WAIT1->FIN_WAIT2状态，现在客户端A只需等待服务端B发送FIN报文请求释放连接即可
B—>A：序号seq = z，确认号ack = x+1（如果步骤2之后直接3，B也正好没有想传的数据时），FIN=1;
当服务端B也把自己该发送的数据发送完成，也会给客户端发送一个FIN报文，且指定一个序列号，此时服务端B 由CLOSE_WAIT->LAST_ACK状态，等待客户端A的ACK报文;
A—>B：序号seq = x+1，确认号ack = z+1，FIN=0，此时客户端处于 TIME_WAIT （时间等待）状态, 服务端B收到后 —>CLOSED

FIN：和SYN相反，SYN请求建立连接，那么FIN报文就是请求断开连接
seq：报文首个字节的序号
ACK：确认报文
ack：确认号，希望收到下一个报文的首个字节的序号

为什么 TIME-WAIT 状态必须等待 2MSL 的时间呢？

为了保证 A 发送的最后一个 ACK 报文段能够到达 B。这个 ACK 报文段有可能丢失，因而使处在 LAST-ACK 状态的 B 收不到对已发送的 FIN + ACK 报文段的确认。B 会超时重传这个 FIN+ACK 报文段，而 A 就能在 2MSL 时间内（超时 + 1MSL 传输）收到这个重传的 FIN+ACK 报文段。接着 A 重传一次确认，重新启动 2MSL 计时器。最后，A 和 B 都正常进入到 CLOSED 状态。如果 A 在 TIME-WAIT 状态不等待一段时间，而是在发送完 ACK 报文段后立即释放连接，那么就无法收到 B 重传的 FIN + ACK 报文段，因而也不会再发送一次确认报文段，这样，B 就无法按照正常步骤进入 CLOSED 状态。

2. 防止已失效的连接请求报文段出现在本连接中。A 在发送完最后一个 ACK 报文段后，再经过时间 2MSL，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

TIME_WAIT 状态会导致什么问题，怎么解决

我们考虑高并发短连接的业务场景，在高并发短连接的 TCP 服务器上，当服务器处理完请求后主动请求关闭连接，这样服务器上会有大量的连接处于 TIME_WAIT 状态，服务器维护每一个连接需要一个 socket，也就是每个连接会占用一个文件描述符，而文件描述符的使用是有上限的，如果持续高并发，会导致一些正常的连接失败。

解决方案：使得服务器处于 TIME-WAIT 状态下的端口能够快速回收和重用。不再等待 2MSL 的时间

TCP与UDP有哪些区别？各自应用场景？

TCP是面向连接(Connection oriented)的协议，UDP是无连接(Connection less)协议；

TCP无界，UDP有界；

TCP可靠，UDP不可靠；

TCP有序，UDP无序；

TCP有流量控制（拥塞控制），UDP没有；

TCP的头部比UDP大；

TCP 一对一，UDP随意

应用场景

TCP应用场景：效率要求相对低，但对准确性要求相对高的场景。因为传输中需要对数据确认、重发、排序等操作，相比之下效率没有UDP高。举几个例子：文件传输（准确高要求高、但是速度可以相对慢）、接受邮件、远程登录。

UDP应用场景：效率要求相对高，对准确性要求相对低的场景。举几个例子：QQ聊天、在线视频、网络语音电话（即时通讯，速度要求高，但是出现偶尔断续不是太大问题，并且此处完全不可以使用重发机制）、广播通信（广播、多播）。

TCP无界，UDP有界是指？

TCP面向字节流无界，UDP面向报文有界；

TCP通过字节流传输，即TCP将应用程序看成是一连串的无结构的字节流，（并不是说不用报文传输）。每个TCP套接口有一个发送缓冲区，如果字节流太长时，TCP会将其拆分进行发送。当字节流太短时，TCP会等待缓冲区中的字节流达到一定程度时再构成报文发送出去，TCP发给对方的数据，对方在收到数据时必须给矛确认，只有在收到对方的确认时，本方TCP才会把TCP发送缓冲区中的数据删除。

而UDP传输报文的方式是由应用程序控制的，应用层交给UDP多长的报文，UDP照样发送，既不拆分，也不合并，而是保留这些报文的边界，即一次发送一个报文。

有界与无界之分是根据接收报文来划分的

对于TCP协议，客户端连续发送数据，只要服务端的这个函数的缓冲区足够大，会一次性接收过来，即客户端是分好几次发过来，是有边界的，而服务端却一次性接收过来，所以证明是无边界的；

而对于UDP协议，客户端连续发送数据，即使服务端的这个函数的缓冲区足够大，也只会一次一次的接收，发送多少次接收多少次，即客户端分几次发送过来，服务端就必须按几次接收，从而证明，这种UDP的通讯模式是有边界的。

TCP字节流和UDP数据报区别

两者的区别在于TCP接收的是一堆数据，而每次取多少由主机决定;而UDP发的是数据报，客户发送多少就接收多少。

拥有这些区别的原因是由于TCP和UDP的特性不同而决定的。TCP是面向连接的，也就是说，在连接持续的过程中，socket中收到的数据都是由同一台主机发出的，因此，知道保证数据是有序的到达就行了，至于每次读取多少数据自己看着办。

而UDP是无连接的协议，也就是说，只要知道接收端的IP和端口，且网络是可达的，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。比如，主机A向发送了报文P1，主机B发送了报文P2，如果能够读取超过一个报文的数据，那么就会将P1和P2的数据合并在了一起，这样的数据是没有意义的。

TCP如何进行面向字节流的数据传输

而TCP是把字节数据丢到TCP缓冲区，等发送时会不时地从缓存中取一块数据并临时加上TCP首部字段，形成TCP报文段，并下传到网络层，网络层进一步封装；接受方接收到TCP数据报后，舍弃TCP首部，然后按序放入TCP缓存区中。由于放入TCP缓存区时，已经是纯粹的字节数据了，难以区分哪些字节数据原本是"打算当作一个整体"读取的，所以TCP会有粘包、拆包问题。（TCP开发，往往需要自己给TCP数据添加一些边界标识和数据长度，方便处理粘包、拆包问题）。

从缓存中取一块数据的大小受限于 MSS最大传输单元

TCP的主要特点

面向连接，数据传输前需要建立连接
点对点，主机对主机
可靠传输，无差错，不丢失，按序达
拥塞控制，网络出现拥塞会使源主机的发送速率降低
全双工，发送端双方都有缓存来临时存放数据
字节流，TCP 把应用程序交下来的数据仅仅看成是一连串的无结构的字节流。

UDP的主要特点

UDP 是无连接的；
UDP 使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态（这里面有许多参数）；
UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如直播，实时视频会议等）；
UDP 支持一对一、一对多、多对一和多对多的交互通信；
UDP 的首部开销小，只有 8 个字节，比 TCP 的 20 个字节的首部要短。

TCP如何实现可靠传输

数据包校验：目的是检测数据在传输过程中的任何变化，若校验出包有错，则丢弃报文段并且不给出响应，这时 TCP 发送数据端超时后会重发数据；
序号：对失序数据包重排序，既然 TCP 报文段作为 IP 数据报来传输，而 IP 数据报的到达可能会失序，因此 TCP 报文段的到达也可能会失序。TCP 将对失序数据进行重新排序；对于重复数据，能够丢弃重复数据；然后才交给应用层；
应答机制：当 TCP 收到发自 TCP 连接另一端的数据，它将发送一个确认。告诉对方此数据已收到；
重传机制（超时重传，快速重传）：滑动窗口协议提升重传机制的效率；累计确认提升滑动窗口协议传输效率；选择性确认在累计确认的基础上提升了丢失报文后数据传输的效率；
流量控制：TCP 连接的每一方都有固定大小的缓冲空间。TCP 的接收端只允许另一端发送接收端缓冲区所能接纳的数据，这可以防止较快主机致使较慢主机的缓冲区溢出，这就是流量控制。TCP 使用的流量控制协议是可变大小的滑动窗口协议。

谈下你对流量控制的理解？

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。

谈谈你对滑动窗口的了解？

滑动窗口是一种考虑对方缓存情况的流量控制技术；

滑动窗口包含的数据由两部分组成（发送窗口）已发送未确认数据，（可用窗口）未发送数据；窗口的大小重复考虑接收方缓存的接受能力；

当可用为 0 时，发送方一般不能再发送数据报

但有两种情况除外，一种情况是可以发送紧急数据，例如，允许用户终止在远端机上的运行进程。另一种情况是发送方可以发送一个 1 字节的数据报来通知接收方重新声明它希望接收的下一字节及发送方的滑动窗口大小。

随着收到ACK包的到来，窗口慢慢移动；继续传输数据；

TCP 如何进行拥塞控制原理

TCP的拥塞控制采用了四种算法：1.慢启动2.拥塞避免3.快重传4.快恢复

慢启动+拥塞窗口+阈值+拥塞避免

发送数据的size为拥塞窗口和接受窗口的较小者

慢启动：拥塞窗口初始化1 每经过一个往返时间RTT 指数级翻倍增长

拥塞避免：拥塞窗口到达阈值后+1增长；

快重传，快恢复

快重传：在 TCP 传输过程中，如果发生了丢包，接收端就会发送之前重复 ACK，比如第 5 个包丢了，6、7 达到，然后接收端会为 5，6，7 都发送第4个包的 ACK，这个时候发送端受到了 3 个重复的 ACK，意识到丢包了，就会马上进行重传，而不用等到 RTO （超时重传的时间）

快恢复：出现拥塞（丢包），拥塞窗口不是降为1，而是降为原来的1/2, 拥塞窗口大小变为拥塞阈值, 接着拥塞窗口再进行线性增加，以适应网络状况

刚刚提到的超时重传的原理是？

超时重传时间：

超时重传时间我们一般用 RTO（Retransmission Timeout）来表示，那么，这个 RTO 设置为多少最合适呢，也就是说经过多长时间进行重传最好？

在这之前，我们先讲解一下 RTT（Round-Trip Time 往返时延）的概念：就是报文段的往返时间显然超时重传的

显然RTO应略微大于RTT即可

如果RTO远大于RTT，就会造成网络空闲时间过长，效率下降
如果RTO小于RTT，那么就会造成不必要的重传，资源浪费

如果超时重传也失败了，每次的等待时间都会成倍增长，1-2-4-8，但是这会导致一个问题，就是周期太长了，效率比较低，那么有没有什么改进的方法呢？——快速重传

谈谈你对停止等待协议的理解？

它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组；

在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。主要包括以下几种情况：

无差错情况
出现差错情况：发送包丢失、确认包丢失（超时重传）和确认迟到（无为）。

谈谈你对 ARQ 协议的理解？

Automatic Repeat-reQuest 自动重传请求

自动重传请求 ARQ 协议

其实是停止等待协议的一部分，不过主要是针对异常情况；

超时重传是指只要超过一段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完一个分组需要设置一个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长一些。

这种自动重传方式常称为自动重传请求 ARQ。

连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了，常用于滑动窗口一起用

为什么ARP查询要在广播帧中发送,而ARP响应要用单播帧

查询前是不知道目的主机具体的mac地址，通过广播的方式，让局域网所有主机收到这个以太网帧，而只有目的主机会从接收的帧中解出ip数据报并知道了源主机的ip地址，然后发送一个arp响应的时候就只需要单播就能找到源主机了

什么是粘包和拆包？

在进行 Java NIO 学习时，可能会发现：如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；
从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

基于上面，在使用 TCP 传输数据时，才有粘包或者拆包现象发生的可能。一个数据包中包含了发送端发送的两个数据包的信息，这种现象即为粘包。

粘包：

要发送的数据小于TCP发送缓冲区的大小，TCP将多次写入缓冲区的数据一次发送出去；
接收数据端的应用层没有及时读取接收缓冲区中的数据；
数据发送过快，数据包堆积导致缓冲区积压多个数据后才一次性发送出去(如果客户端每发送一条数据就睡眠一段时间就不会发生粘包)；

拆包：

过大的数据（大于MSS）会被拆分，报文传输中又出现粘包，不属于同一数据段的部分合在了一起；

怎么解决拆包和粘包？

分包机制一般有两个通用的解决方法：

特殊字符控制；
在包头首都添加数据包的长度。

如果使用 netty 的话，就有专门的编码器和解码器解决拆包和粘包问题了。

tips：UDP 没有粘包问题，但是有丢包和乱序。不完整的包是不会有的，收到的都是完全正确的包。传送的数据单位协议是 UDP 报文或用户数据报，发送的时候既不合并，也不拆分。

TCP 最大连接数限制

端口

如何标识一个TCP连接

在确定最大连接数之前，先来看看系统如何标识一个tcp连接。系统用一个4四元组来唯一标识一个TCP连接：{local ip, local port,remote ip,remote port}。

client最大tcp连接数

client每次发起tcp连接请求时，除非绑定端口，通常会让系统选取一个空闲的本地端口（local port），该端口是独占的，不能和其他tcp连接共享。tcp端口的数据类型是unsigned short，因此本地端口个数最大只有65536，端口0有特殊含义，不能使用，这样可用端口最多只有65535，所以在全部作为client端的情况下，最大tcp连接数为65535，这些连接可以连到不同的server ip。

server最大tcp连接数

server通常固定在某个本地端口上监听，等待client的连接请求。

不考虑地址重用（unix的SO_REUSEADDR选项）的情况下，即使server端有多个ip，本地监听端口也是独占的，因此server端tcp连接4元组中只有remote ip（也就是client ip）和remote port（客户端port）是可变的，因此最大tcp连接为客户端ip数×客户端port数

对IPV4，不考虑ip地址分类等因素，最大tcp连接数约为2的32次方（ip数）×2的16次方（port数），也就是server端单机最大tcp连接数约为2的48次方。

实际的tcp连接数

上面给出的是理论上的单机最大连接数，在实际环境中，受到机器资源、操作系统等的限制，特别是sever端，其最大并发tcp连接数远不能达到理论上限。在unix/linux下限制连接数的主要因素是内存和允许的文件描述符个数（每个tcp连接都要占用一定内存，每个socket就是一个文件描述符），另外1024以下的端口通常为保留端口。在默认2.6内核配置下，经过试验，每个socket占用内存在15~20k之间。

影响一个socket占用内存的参数包括：

rmem_max

wmem_max

tcp_rmem

tcp_wmem

tcp_mem

grep skbuff /proc/slabinfo

对server端，通过增加内存、修改最大文件描述符个数等参数，单机最大并发TCP连接数超过10万是没问题的，国外 Urban Airship 公司在产品环境中已做到 50 万并发。在实际应用中，对大规模网络应用，还需要考虑C10K 问题。

HTTP1.0，1.1，2.0 的版本区别

HTTP 1.0 : 默认短连接，每次请求和响应，都要建立连接，连接无法复用；HTTP1.0 其实也可以强制开启长链接，例如接受Connection: keep-alive这个字段，但是，这不是标准字段，不同实现的行为可能不一致，因此不是根本的解决办法。

HTTP 1.1：默认长连接，TCP连接复用，一方主动放弃来连接才断开；管道机制排队等待，多个请求可以同时发送，但请求必须一个一个处理，出现队列等待阻塞；

HTTP 2.0: 多路复用；二进制数据；Header压缩；服务推送

多路复用：同时发送或者接受多个请求和响应，请求和响应有编号，同一个连接并发处理多个请求，不需要等待，解决队列等待阻塞；

POST和GET有哪些区别？各自应用场景？

POST：提交数据，可能会修改服务器的数据；对服务器可能有威胁（注册信息，上传文件）

GET：只读服务器数据；对服务器没有威胁（查看页面）

HTTP 状态码

2 成功；3重定向；4客户端请求报文错误； 5服务端错误

301：永久重定向，请求资源不在，用新的URL访问，表示该资源已经永久改变了位置。

302：临时重定向，资源还在，但用另外一个URL访问

403：禁止访问的资源

404：资源无

501：功能还不支持

502：后端服务器异常

503：服务器忙，由于临时的服务器维护或者过载，服务器当前无法处理请求。这个状况是临时的，并且将在一段时间以后恢复。某一时刻大量登录，比如学校返校登记网站。由于需要48核酸证明，某一时段会过载登录。

301 302应用场景

301

网页开发过程中，时常会遇到网站目录结构的调整，将页面转移到一个新地址；网页扩展名的改变，这些变化都会导致网页地址发生改变，此时用户收藏夹和搜索引擎数据库中的旧地址是一个错误的地址，访问之后会出现404页面，直接导致网站流量的损失。或者是我们需要多个域名跳转至同一个域名，例如本站主站点域名为 http://www.conimi.com ，而还有一个域名 http://www.nico.cc，由于对该域名设置了301重定向，当输入http://www.nico.cc 时，自动跳转至 http://www.conimi.com 。

302

302重定向（302 Move Temporarily），指页面暂时性转移，表示资源或页面暂时转移到另一个位置，常被用作网址劫持，容易导致网站降权，严重时网站会被封掉，不推荐使用。

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

connetion:keep-alive;

HTTP 如何实现长连接？在什么时候会超时？

实际上 HTTP 没有长短链接，只有 TCP 有，TCP 长连接可以复用一个 TCP 链接来发起多次 HTTP 请求，这样可以减少资源消耗，比如一次请求 HTML，可能还需要请求后续的 JS/CSS/图片等

通过在头部（请求和响应头）设置 Connection: keep-alive，HTTP1.0协议支持，但是默认关闭，从HTTP1.1协议以后，连接默认都是长连接

1、HTTP 一般会有 httpd 守护进程，里面可以设置 keep-alive timeout，当 tcp 链接闲置超过这个时间就会关闭，也可以在 HTTP 的 header 里面设置超时时间

2、TCP 的 keep-alive 包含三个参数，支持在系统内核的 net.ipv4 里面设置：当 TCP 链接之后，闲置了 tcp_keepalive_time，则会发生侦测包，如果没有收到对方的 ACK，那么会每隔 tcp_keepalive_intvl 再发一次，直到发送了 tcp_keepalive_probes，就会丢弃该链接。

（1）tcp_keepalive_intvl = 15
（2）tcp_keepalive_probes = 5
（3）tcp_keepalive_time = 1800

谈下你对 HTTP 长连接和短连接的理解？分别应用于哪些场景？

在 HTTP/1.0 中默认使用短连接。也就是说，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个 HTML 或其他类型的 Web 页中包含有其他的 Web 资源（如：JavaScript 文件、图像文件、CSS 文件等），每遇到这样一个 Web 资源，浏览器就会重新建立一个 HTTP 会话。

而从 HTTP/1.1 起，默认使用长连接，用以保持连接特性。使用长连接的 HTTP 协议，会在响应头加入这行代码：

Connection:keep-alive

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。

Keep-Alive 不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如：Apache）中设定这个时间。实现长连接需要客户端和服务端都支持长连接。

应用场景

长连接多用于操作频繁，点对点的通。数据库的连接用长连接，如果用短连接频繁的通信会造成 socket 错误，而且频繁的 socket创建也是对资源的浪费。

短连接多用于服务端连接多，每个连接操作不频繁。WEB 网站的 http 服务一般都用，因为长连接对于服务端来说会耗费一定的资源，像 WEB 网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连接。

简单说下 HTTPS 和 HTTP 的区别

HTTPS 比HTTP多加密传输；

具体实现方法是：连接时需要先建立SSL/TLS的连接再建立三次握手；

建立SSL/TLS的连接基本流程：客户端向服务器索要并验证服务器的公钥；双方协商 生成会话密钥；采用密钥进行加密通信

SSL/TLS 主要技术包括非对称加密数字证书数字签名；

非对称加密：主要是用于后续对称加密的传输的密钥交换

数字证书：验证非对称加密时，公钥的真实性

数字签名：验证建立SSL/TLS的连接时，双方传输的数据是否遭到篡改，同时验证数据来源

HTTPS 的工作过程？

主要工作过程就是是通过非对称加密获取用于对称加密的密钥，而后通过对称加密进行数据传输；

具体细节如下

1.客户端发送请求信息信息包括客户端支持的加密算法列表、随机数1

加密算法包括：作为计算对称加密会话密钥的算法；用于摘要计算的 hash算法；等

2.服务端发送响应信息包括数字证书，确认的加密算法 、随机数2

3.客户端验证服务器数字证书的合法性，约定好的hash算法计算客户端摘要，从数字证书获取 服务器的公钥加密响应数据

响应数据包括随机数3、客户端摘要；

此时客户端使用约定好的加密算法利用三个随机数计算会话密钥

4.服务端使用自己的私钥解密数据；解析验证客户端摘要；使用约定好的加密算法利用三个随机数计算会话密钥；约定好的hash算法计算服务端摘要

至此一个非对称加密的过程结束

后续使用对称加密传输数据

摘要用于验证双方数据的完整性

总结

① 证书验证阶段

浏览器发起 HTTPS 请求
服务端返回 HTTPS 证书
客户端验证证书是否合法，如果不合法则提示告警

② 数据传输阶段

当证书验证合法后，在本地生成随机数
通过公钥加密随机数，并把加密后的随机数传输到服务端
服务端通过私钥对随机数进行解密
服务端通过客户端传入的随机数构造对称加密算法，对返回结果内容进行加密后传输

为什么HTTPS数据传输是用对称加密？

首先，非对称加密的加解密效率是非常低的，而 http 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的；另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。

为什么需要 CA 认证机构颁发证书？

HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的 “中间人攻击” 问题。

“中间人攻击”的具体过程如下：

过程原理：

本地请求被劫持（如DNS劫持等），所有请求均发送到中间人的服务器
中间人服务器返回中间人自己的证书
客户端创建随机数，通过中间人证书的公钥对随机数加密后传送给中间人，然后凭随机数构造对称加密对传输内容进行加密传输
中间人因为拥有客户端的随机数，可以通过对称加密算法进行内容解密
中间人以客户端的请求内容再向正规网站发起请求
因为中间人与服务器的通信过程是合法的，正规网站通过建立的安全通道返回加密后的数据
中间人凭借与正规网站建立的对称加密算法对内容进行解密
中间人通过与客户端建立的对称加密算法对正规内容返回的数据进行加密传输
客户端通过与中间人建立的对称加密算法对返回结果数据进行解密

由于缺少对证书的验证，所以客户端虽然发起的是 HTTPS 请求，但客户端完全不知道自己的网络已被拦截，传输内容被中间人全部窃取。

什么是数字签名？

数字签名是非对称加密和摘要算法的应用

两端都有对方的公钥

约定hash 为传输的原数据计算独一无二的指纹；

将指纹和原数据利用公钥加密，传输给对方

对方使用自己的私钥解密，并使用约定hash 为获取的数据计算摘要与“指纹”对比

一致则表明数据来源于对方，且数据并未被篡改

什么是数字证书？

对称加密中，双方使用公钥进行解密。虽然数字签名可以保证数据不被替换，但是数据是由公钥加密的，如果公钥也被替换，则仍然可以伪造数据，因为用户不知道对方提供的公钥其实是假的。

中间人可以伪造证书与客户端来连接，将服务端的数据篡改，狸猫换太子；

为了保证发送方的公钥是真的，CA 证书机构会负责颁发一个证书，里面的公钥保证是真的，用户请求服务器时，服务器将证书发给用户，这个证书是经由系统内置证书的备案的，且与域名绑定；

浏览器是如何确保 CA 证书的合法性？

浏览器发起 HTTPS 请求时，服务器会返回网站的 SSL 证书，浏览器需要对证书做以下验证：

验证域名、有效期等信息是否正确。证书上都有包含这些信息，比较容易完成验证；
判断证书来源是否合法。每份签发证书都可以根据验证链查找到对应的根证书，操作系统、浏览器会在本地存储权威机构的根证书，利用本地根证书可以对对应机构签发证书完成来源验证；

3.判断证书是否被篡改。需要与 CA 公钥进行校验；如果此时证书被篡改，CA公钥无法解密，浏览器会提示警告，用户可以选择继续访问，之后浏览器会使用对方的公钥传输用于对称加密的密钥信息

以上任意一步都满足的情况下浏览器才认为证书是合法的。

这里插一个我想了很久的但其实答案很简单的问题：
既然证书是公开的，如果要发起中间人攻击，我在官网上下载一份证书作为我的服务器证书，那客户端肯定会认同这个证书是合法的，如何避免这种证书冒用的情况？
其实这就是非加密对称中公私钥的用处，虽然中间人可以得到证书，但证书中室友CA签名的，这个签名是由CA私钥加密的无法解析，同时签名的数据包含服务器的公钥信息。中间人无法获得CA私钥，无法签名，也就无法篡改。

只有认证机构可以生成证书吗？

如果需要浏览器不提示安全风险，那只能使用认证机构签发的证书。

但浏览器通常只是提示安全风险，并不限制网站不能访问，所以从技术上谁都可以生成证书，只要有证书就可以完成网站的HTTPS 传输。例如早期的 12306 采用的便是手动安装私有证书的形式实现 HTTPS 访问。

这种情况下就可能出现中间人攻击

本地随机数被窃取怎么办？

证书验证是采用非对称加密实现，但是传输过程是采用对称加密，而其中对称加密算法中重要的随机数是由本地生成并且存储于本地的HTTPS

如何保证随机数不会被窃取？其实 HTTPS 并不包含对随机数的安全保证，HTTPS保证的只是传输过程安全，而随机数存储于本地，本地的安全属于另一安全范畴，应对的措施有安装杀毒软件、反木马、浏览器升级修复漏洞等。

用了 HTTPS 会被抓包吗？

HTTPS 的数据是加密的，常规下抓包工具代理请求后抓到的包内容是加密状态，无法直接查看。但是，正如前文所说，浏览器只会提示安全风险，如果用户授权仍然可以继续访问网站，完成请求。因此，只要客户端是我们自己的终端，我们授权的情况下，便可以组建中间人网络，而抓包工具便是作为中间人的代理。

通常HTTPS抓包工具的使用方法是会生成一个证书，用户需要手动把证书安装到客户端中，然后终端发起的所有请求通过该证书完成与抓包工具的交互，然后抓包工具再转发请求到服务器，最后把服务器返回的结果在控制台输出后再返回给终端，从而完成整个请求的闭环。

既然 HTTPS 不能防抓包，那 HTTPS 有什么意义？

HTTPS可以防止用户在不知情的情况下通信链路被监听，对于主动授信的抓包操作是不提供防护的，因为这个场景用户是已经对风险知情。要防止被抓包，需要采用应用级的安全防护，例如采用私有的对称加密，同时做好移动端的防反编译加固，防止本地算法被破解。

Cookie 和 Session 有什么区别？

Cookie 将登陆等信息保存在客户端

Session将信息保存在服务端

1、由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session.典型的场景比如购物车。

当你点击下单按钮时，由于HTTP协议无状态，所以并不知道是哪个用户操作的，所以服务端要为特定的用户创建了特定的Session，用用于标识这个用户，并且跟踪用户，这样才知道购物车里面有几本书。

这个Session是保存在服务端的，有一个唯一标识。在服务端保存Session的方法很多，内存、数据库、文件都有。集群的时候也要考虑Session的转移，在大型的网站，一般会有专门的Session服务器集群，用来保存用户会话，这个时候 Session 信息都是放在内存的，使用一些缓存服务比如Memcached之类的来放 Session。

2、思考一下服务端如何识别特定的客户？这个时候Cookie就登场了。每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session的时候，服务端会在HTTP协议中告诉客户端，需要在 Cookie 里面记录一个Session ID，以后每次请求把这个会话ID发送到服务器，我就知道你是谁了。

有人问，如果客户端的浏览器禁用了 Cookie 怎么办？一般这种情况下，会使用一种叫做URL重写的技术来进行会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sid=xxxxx 这样的参数，服务端据此来识别用户。

3、Cookie其实还可以用在一些方便用户的场景下，设想你某次登陆过一个网站，下次登录的时候不想再次输入账号了，怎么办？这个信息可以写到Cookie里面，访问网站的时候，网站页面的脚本可以读取这个信息，就自动帮你把用户名给填了，能够方便一下用户。这也是Cookie名称的由来，给用户的一点甜头。

所以，总结一下：

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在集群、数据库、文件中。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

GET请求中URL编码的意义

请求数据信息在URL 中

以键值对的形式展现

键值对： key=value

键值对连接使用 &

如果键值对中就包含 = 或 & 这种特殊字符的时候，使用转义字符 %+特殊字符

forward 和 redirect 的区别？

其实都是资源跳转方式

转发：forward

在服务器内部的资源跳转方式

浏览器地址栏不发生变化
只能转发当前服务器内部资源
转发是一次请求

重定向:redirect

重定向：客户端服务器请求服务，服务器响应另一个服务器的地址，是客户端向该服务器发出请求（各种网络请求重新定个方向转到其它位置）

地址栏发生变化
重定向可以访问其他站点(服务器)的资源
重定向是两次请求。不能使用request对象来共享数据

体会

不涉及到数据共享，用重定向；需要共享用转发

有时候，数据共享，可能会导致非必要参数的显示

Forward 和 Redirect 代表了两种请求转发方式：直接转发和间接转发。

直接转发方式（Forward）：客户端和浏览器只发出一次请求，Servlet、HTML、JSP 或其它信息资源，由第二个信息资源响应该请求，在请求对象 request 中，保存的对象对于每个信息资源是共享的。

间接转发方式（Redirect）：实际是两次 HTTP 请求，服务器端在响应第一次请求的时候，让浏览器再向另外一个 URL 发出请求，从而达到转发的目的。

在浏览器中输入 URL 地址到显示主页的过程？

URL解析（URL 包括协议名称；服务器域名；访问的数据位置）

生成HTTP报文

DNS域名解析

传输层数据分割与封装，建立连接；网络层封装，确定目标地址

发送请求

服务器收到请求，根据请求资源返回

浏览器解析渲染页面：浏览器解析并渲染视图，若遇到对 js 文件、css 文件及图片等静态资源的引用，则重复上述步骤并向服务器请求这些资源；浏览器根据其请求到的资源、数据渲染页面，最终向用户呈现一个完整的页面。

URL 与 URI的关系

URL，即统一资源定位符 (Uniform Resource Locator )，URL 其实就是我们平时上网时输入的网址，它标识一个互联网资源，并指定对其进行操作或获取该资源的方法。例如 https://leetcode-cn.com/problemset/all/ 这个 URL，标识一个特定资源并表示该资源的某种形式是可以通过 HTTP 协议从相应位置获得。

URL包含以下信息：

1、用于访问资源的协议

2、服务器的位置（无论是通过IP地址还是域名）

3、服务器上的端口号（可选）

4、资源在服务器目录结构中的位置

而 URI 则是统一资源标识符，并不是一个直接访问的链接，而是相对地址

URL 是 URI 的一个子级，两者都定义了资源是什么，而 URL 还定义了如何能访问到该资源。URI 是一种语义上的抽象概念，可以是绝对的，也可以是相对的，而URL则必须提供足够的信息来定位，是绝对的。简单地说，只要能唯一标识资源的就是 URI，在 URI 的基础上给出其资源的访问方式的就是 URL。

DNS 的解析过程

根域名：. 根域的DNS服务器保存着互联网中所有的DNS服务器

顶级域名：com、cn、net、org、edu、gov 等

二级域名：baidu 等（我们需要注册的就是到这个层级的，因为二级域名就已经是全球唯一的了。）

主机名：www、mail等

DNS 的解析过程

主机问本地DNS

本地DNS 问根DNS

根DNS 让本地服务器找 顶级域名

顶级域名 让本地服务器找 二级域名

具体细节

主机向本地域名服务器的查询一般都是采用递归查询。所谓递归查询就是：如果主机所询问的本地域名服务器不知道被查询的域名的 IP 地址，那么本地域名服务器就以 DNS 客户的身份，向根域名服务器继续发出查询请求报文(即替主机继续查询)，而不是让主机自己进行下一步查询。因此，递归查询返回的查询结果或者是所要查询的 IP 地址，或者是报错，表示无法查询到所需的 IP 地址。
本地域名服务器向根域名服务器的查询的迭代查询。迭代查询的特点：当根域名服务器收到本地域名服务器发出的迭代查询请求报文时，要么给出所要查询的 IP 地址，要么告诉本地服务器：“你下一步应当向哪一个域名服务器进行查询”。然后让本地服务器进行后续的查询。根域名服务器通常是把自己知道的顶级域名服务器的 IP 地址告诉本地域名服务器，让本地域名服务器再向顶级域名服务器查询。顶级域名服务器在收到本地域名服务器的查询请求后，要么给出所要查询的 IP 地址，要么告诉本地服务器下一步应当向哪一个权限域名服务器进行查询。最后，本地域名服务器得到了所要解析的 IP 地址或报错，然后把这个结果返回给发起查询的主机。

谈谈你对域名缓存的了解？

以根域名为例

所有域名查询都必须先查询根域名，因为只有根域名才能告诉你，某个顶级域名由哪台服务器管理。事实上也确实如此，ICANN 维护着一张列表，里面记载着顶级域名和对应的托管商。

比如，我要访问www.example.com，就必须先询问 ICANN 的根域名列表，它会告诉我.com域名由 Verisign 托管，我必须去找 Verisign，它会告诉我example.com服务器在哪里。

再比如，我要访问abc.xyz，也必须先去询问根域名列表，它会告诉我.xyz域名由 CentralNic 公司托管。根域名列表还记载，.google由谷歌公司托管，.apple由苹果公司托管等等。

由于根域名列表很少变化，大多数 DNS 服务商都会提供它的缓存，所以根域名的查询事实上不是那么频繁。

以本地域名服务器为例

为了提高 DNS 查询效率，并减轻服务器的负荷和减少因特网上的 DNS 查询报文数量，在域名服务器中广泛使用了高速缓存，用来存放最近查询过的域名以及从何处获得域名映射信息的记录。

由于名字到地址的绑定并不经常改变，为保持高速缓存中的内容正确，域名服务器应为每项内容设置计时器并处理超过合理时间的项（例如：每个项目两天）。当域名服务器已从缓存中删去某项信息后又被请求查询该项信息，就必须重新到授权管理该项的域名服务器绑定信息。当权限服务器回答一个查询请求时，在响应中都指明绑定有效存在的时间值。增加此时间值可减少网络开销，而减少此时间值可提高域名解析的正确性。

不仅在本地域名服务器中需要高速缓存，在主机中也需要。许多主机在启动时从本地服务器下载名字和地址的全部数据库，维护存放自己最近使用的域名的高速缓存，并且只在从缓存中找不到名字时才使用域名服务器。维护本地域名服务器数据库的主机应当定期地检查域名服务器以获取新的映射信息，而且主机必须从缓存中删除无效的项。由于域名改动并不频繁，大多数网点不需花精力就能维护数据库的一致性。

DNS 为什么用 UDP

其实 DNS 的整个过程是既使用 TCP 又使用 UDP。

当进行区域传送（主域名服务器向辅助域名服务器传送变化的那部分数据）时会使用 TCP，因为数据同步传送的数据量比一个请求和应答的数据量要多，而 TCP 允许的报文长度更长，因此为了保证数据的正确性，会使用基于可靠连接的 TCP。

使用UDP的原因是 UDP极其适合传输数据量不超过500字节的数据；这种数据量不会分割一定程度上规避了UDP传输不可靠等问题，又发挥了UDP高效等优点

当客户端向 DNS 服务器查询域名 ( 域名解析) 的时候，一般返回的内容不会超过即 500字节。用 UDP 传输时，不需要经过 TCP 三次握手的过程，从而大大提高了响应速度，但这要求域名解析器和域名服务器都必须自己处理超时和重传从而保证可靠性。

我们知道UDP是不可靠的传输协议，为了减少UDP包丢失的风险，我们最好能控制UDP包在下层协议的传输过程中不要被切割。不过鉴于Internet上的标准MTU值为576字节，所以建议在进行Internet的UDP编程时，最好将UDP的数据长度控制在 (576-8-20)548字节以内。

简单说下怎么实现 DNS 劫持

DNS 劫持即域名劫持，是通过将原域名对应的 IP 地址进行替换从而使得用户访问到错误的网站或者使得用户无法正常访问网站的一种攻击方式。域名劫持往往只能在特定的网络范围内进行，范围外的 DNS 服务器能够返回正常的 IP 地址。攻击者可以冒充原域名所属机构，通过电子邮件的方式修改组织机构的域名注册信息，或者将域名转让给其它组织，并将新的域名信息保存在所指定的 DNS 服务器中，从而使得用户无法通过对原域名进行解析来访问目的网址。

用户端的一些预防手段：

直接通过 IP 地址访问网站，避开 DNS 劫持。
由于域名劫持往往只能在特定的网络范围内进行，因此一些高级用户可以通过网络设置让 DNS 指向正常的域名服务器以实现对目的网址的正常访问，例如将计算机首选 DNS 服务器的地址固定为 8.8.8.8。

什么是SQL 注入？举个例子？

概念：SQL注入就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。

总体思路：(1). 寻找到SQL注入的位置；(2). 判断服务器类型和后台数据库类型；(3). 针对不同的服务器和数据库特点进行SQL注入攻击

实例

比如，在一个登录界面，要求输入用户名和密码，可以这样输入实现免帐号登录：

用户名： ‘or 1 = 1 --

密码：

用户一旦点击登录，如若没有做特殊处理，那么这个非法用户就很得意的登陆进去了。这是为什么呢?

下面我们分析一下：从理论上说，后台认证程序中会有如下的SQL语句：

String sql = “select * from user_table where username=’ “+userName+” ’ and password=’ “+password+” ‘”;

因此，当输入了上面的用户名和密码，上面的SQL语句变成：

SELECT * FROM user_table WHERE username=’’or 1 = 1 –- and password=’’

分析上述SQL语句我们知道，username=‘' or 1=1 这个语句一定会成功；然后后面加两个 -，这意味着注释，它将后面的语句注释，让他们不起作用。这样，上述语句永远都能正确执行，用户轻易骗过系统，获取合法身份。

应对方法

(1)参数绑定

使用预编译手段，绑定参数是最好的防SQL注入的方法。目前许多的ORM框架及JDBC等都实现了SQL预编译和参数绑定功能，攻击者的恶意SQL会被当做SQL的参数而不是SQL命令被执行。在mybatis的mapper文件中，对于传递的参数我们一般是使用 # 和$来获取参数值。

update user set username=#{username},password=#{password} where id=#{id}

</update></mapper>

当使用$时，变量就是直接追加在sql中，一般会有sql注入问题。

当使用#时，变量是占位符，就是一般我们使用javajdbc的PrepareStatement时的占位符，所以可以防止sql注入；

PreparedStatement s = null;//定义sql语句String sql = "select * from users where username = ? and password = ?";s = c.prepareStatement(sql);s.setString(1,username);s.setString(2,password);

c 是 Connection 数据库连接对象

(2)使用正则表达式过滤传入的参数

IP 分类

IP: 网络号+主机号

A：0XXX;

B：10XX;

C：110X;

D：111X; 保留位多播地址。

E：1111;

另一种分类方式：CIDR 通过子网掩码划分

IP: a.b.c.d/x

前 x 位是网络号，也是子网掩码的位数

IPV4 地址不够如何解决

目前主要有以下两种方式：

1、其实我们平时上网，电脑的 IP 地址都是属于私有地址，我无法出网关，我们的数据都是通过网关来中转的，这个其实 NAT 协议，可以用来暂缓 IPV4 地址不够；

2、IPv6 ：作为接替 IPv4 的下一代互联网协议，其可以实现 2 的 128 次方个地址，而这个数量级，即使是给地球上每一颗沙子都分配一个IP地址，该协议能够从根本上解决 IPv4 地址不够用的问题。

NAT是指？

NAT: 区域内使用私用IP，与外界通信时将私有IP转化成公用IP

内网有很多计算机，每个计算机的私有地址向外界请求都转化成公有地址这并不会缓解IP危机

因此引入NAPT（Network Address Port Translation）

概念：即网络地址端口转换，可将多个内部地址映射为一个合法公网地址，以不同的端口号与不同的内部地址相对应，也就是<不同的内部地址+内部端口>与<一个外部地址+不同外部端口>之间的转换。

IP地址和MAC地址有什么区别？各自的用处？

IP 是用来寻址；

MAC用来确认身份以及 寻址过程中的实际路径传输；

寻址过程中的实际路径传输的意思是：寻址过程每次数据传输都必须要通过 ARP 和目标IP ，得到下一跳的MAC，通过MAC将数据传输过去；

ARP 协议的工作原理？

首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址，如果没有以广播的方式问目标IP的MAC；具体细节如下：

网络层的 ARP 协议完成了 IP 地址与物理地址的映射。

首先，每台主机都会在自己的 ARP 缓冲区中建立一个 ARP 列表，以表示 IP 地址和 MAC 地址的对应关系。

当源主机需要将一个数据包要发送到目的主机时，会首先检查自己 ARP 列表中是否存在该 IP 地址对应的 MAC 地址：如果有，就直接将数据包发送到这个 MAC 地址；如果没有，就向本地网段发起一个 ARP 请求的广播包，查询此目的主机对应的 MAC 地址。

此 ARP 请求数据包里包括源主机的 IP 地址、硬件地址、以及目的主机的 IP 地址。

网络中所有的主机收到这个 ARP 请求后，会检查数据包中的目的 IP 是否和自己的 IP 地址一致。

如果不相同就忽略此数据包；

如果相同，该主机首先将发送端的 MAC 地址和 IP 地址添加到自己的 ARP 列表中，如果 ARP 表中已经存在该 IP 的信息，则将其覆盖，然后给源主机发送一个 ARP 响应数据包，告诉对方自己是它需要查找的 MAC 地址；

源主机收到这个 ARP 响应数据包后，将得到的目的主机的 IP 地址和 MAC 地址添加到自己的 ARP 列表中，并利用此信息开始数据的传输。如果源主机一直没有收到 ARP 响应数据包，表示 ARP 查询失败

ARP欺骗？

当主机A发起ARP请求时，在本网段内询问 IP地址的归属者（MAC）；

主机B冒充IP地址的归属者，A向该IP发送的数据全部流入到B中；

ICMP 有哪些应用？

功能

确认IP包是否成功送达
报告发送中IP包被废弃的原因

类型

ICMP报文的种类有两种，即ICMP差错报文和ICMP询问报文。

差错报告报文有五种（细分的话不止，详情可百度）：终点不可达、源点抑制（Source quench）（已弃用）、时间超过、参数问题、改变路由（重定向）（Redirect）。

访问报文有两种（同样不止，详细百度）：回送请求和回答报文，时间戳请求（弃用）和回答报文。

应用

ICMP 主要有两个应用，一个是 Ping，一个是 Traceroute。

1. Ping

Ping 是 ICMP 的一个重要应用，主要用来测试两台主机之间的连通性。

Ping 的原理是通过向目的主机发送 ICMP Echo 请求报文，目的主机收到之后会发送 Echo 回答报文。Ping 会根据时间和成功响应的次数估算出数据包往返时间以及丢包率。

大致流程：

构造ICMP数据包–>构造IP数据包–>构造以太网数据帧----物理传输到目标主机---->获取以太网数据帧–>解析出IP数据包–>解析出ICMP数据包–>发送回送应答报文

2. Traceroute

Traceroute 是 ICMP 的另一个应用，用来跟踪一个分组从源点到终点的路径。

Traceroute 发送的 IP 数据报封装的是无法交付的 UDP 用户数据报，并由目的主机发送终点不可达差错报告报文。

源主机向目的主机发送一连串的 IP 数据报。第一个数据报 P1 的生存时间 TTL 设置为 1，当 P1 到达路径上的第一个路由器 R1 时，R1 收下它并把 TTL 减 1，此时 TTL 等于 0，R1 就把 P1 丢弃，并向源主机发送一个 ICMP 时间超过差错报告报文；
源主机接着发送第二个数据报 P2，并把 TTL 设置为 2。P2 先到达 R1，R1 收下后把 TTL 减 1 再转发给 R2，R2 收下后也把 TTL 减 1，由于此时 TTL 等于 0，R2 就丢弃 P2，并向源主机发送一个 ICMP 时间超过差错报文。
不断执行这样的步骤，直到最后一个数据报刚刚到达目的主机，主机不转发数据报，也不把 TTL 值减 1。但是因为数据报封装的是无法交付的 UDP，因此目的主机要向源主机发送 ICMP 终点不可达差错报告报文。
之后源主机知道了到达目的主机所经过的路由器 IP 地址以及到达每个路由器的往返时间。

LL大个仔

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
打赏
0
评论
计算机网络面试题

我们考虑高并发短连接的业务场景，在高并发短连接的 TCP 服务器上，当服务器处理完请求后主动请求关闭连接，这样服务器上会有大量的连接处于 TIME_WAIT 状态，服务器维护每一个连接需要一个 socket，也就是每个连接会占用一个文件描述符，而文件描述符的使用是有上限的，如果持续高并发，会导致一些正常的连接失败。比如，主机A向发送了报文P1，主机B发送了报文P2，如果能够读取超过一个报文的数据，那么就会将P1和P2的数据合并在了一起，这样的数据是没有意义的。
复制链接

扫一扫