1. 网络架构

自下而上对各层的作用进行简单介绍：

• 物理层：屏蔽介质和设备差异实现相邻计算机节点之间比特流的透明传输（网卡、集线器）。
• 数据链路层: 将物理层的比特流封装成帧，在相邻结点之间传输，这一层还需要实现差错控制和流量控制（网桥、交换机）。
• 网络层：网络层的任务就是选择合适的网间路由和交换结点，确保数据及时传送（IP、ICMP、IGMP、ARP、RARP）（路由器、三层交换机）。
• 运输层：负责向两台主机进程之间的通信提供通用的数据传输服务(TCP、UDP)，（网关）。
• 会话层: 用户应用程序和网络之间的接口，主要包括用户建立、维护和管理会话。
• 表示层：解释应用层的命令和数据，如编码、数据格式转换和加密解密。
• 应用层：提供应用层协议，如HTTP协议，FTP协议等等，方便应用程序之间进行通信。
  

2. TCP/UDP

2.1 TCP 三次握手

（1） 建立TCP连接的目的：
为了准确无误的把数据送达目标处，TCP采用三次握手策略建立连接。
（2）具体过程：

⼀次握⼿: 客户端–> 发送带有 SYN 标志的数据包       –> 服务端
 ⼆次握⼿: 服务端–> 发送带有 SYN/ACK 标志的数据包   –> 客户端
 三次握⼿: 客户端–> 发送带有带有 ACK 标志的数据包   –> 服务端
​

半连接队列：TCP握手中，当服务器处于SYN_RCVD 状态，服务器会把此种状态下请求连接放在一个队列里，该队列称为半连接队列。
​

SYN攻击:SYN攻击即是利用TCP协议的缺陷，通过发送大量的半连接请求，占用半连接队列，耗费CPU和内存资源。优化方式：（1）缩短SYN Timeout时间； （2）记录IP，若连续受到某个IP的重复SYN报文，从这个IP地址来的包会被一概丢弃。
​

（3）为什么要三次握手，而不是两次或者四次?
答：TCP采用的是全双工的通信方式，三次握手最主要的目的就是通信双方确保自己与对方发送与接收数据的过程是正常的，只有两次的话，客户端这边没有问题，但是服务器端只知道对方发送正常，自己接收正常，不知道客户端接收正常不正常。三次能到达互相确认的目的，因此不需要第四次握手。每一次握手能够到达的效果是:
**  第⼀次握⼿：Client什么都不能确认；Server确认了对⽅发送正常，⾃⼰接收正常。第⼆次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：对⽅发送正常，⾃⼰接收正常。第三次握⼿：Client 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常；Server 确认了：⾃⼰发送、接收正常，对⽅发送、接收正常。
 所以三次握⼿就能确认双发收发功能都正常，缺⼀不可。
（4）为什么要传回SYN？
答： 接收端传回发送端所发送的 SYN 是为了告诉发送端，我接收到的信息确实就是你所发送的信号。
（5）传了SYN，为啥还要传ACK？ （这个回答就和为什么不是两次握手差不多）
答： 双⽅通信⽆误必须是两者互相发送信息都⽆误。传了 SYN，证明发送⽅到接收⽅的通道没有问题，但是接收⽅到发送⽅的通道还需要 ACK 信号来进⾏验证。**

2.2 TCP 四次挥手

（1） 具体过程

（2）为什么要四次挥手？
答：任何⼀⽅都可以在数据传送结束后发出连接释放的通知，待对⽅确认后进⼊半关闭状态。当另⼀⽅也没有数据再发送的时候，则发出连接释放通知，对⽅确认后就完全关闭了TCP连接，因此四次挥手是为了确保通信双方都释放连接。
举个例⼦：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B可能还会有要说的话，A 不能要求 B 跟着⾃⼰的节奏结束通话，于是 B 可能⼜巴拉巴拉说了⼀通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。
（3）为什么还要等待2MSL（最长报文段寿命）？
答：MSL表示报文最大生存时间，等待2MSL主要是：（1）为了确保客户端A发给服务器B的最后一个ACK报文能够到达服务器B，客服端发送给服务端的ACK可能会丢失，服务器收不到ACK会在发送一个FIN给客户端，如果客户端关闭了，服务端永远收不到ACK，就不能正常关闭。（2） 可以保证上一次连接的报文已经在网络中消失，不会出现与新TCP连接报文冲突的情况。

2.3 TCP和UDP的区别?

（1）TCP是面向连接的可靠传输，保证数据的正确性和顺序性，传输效率慢，以字节流的形式传输，TCP通过三次握手和四次挥手建立和释放连接，TCP通过校验和、流量控制和拥塞控制实现可靠传输，主要用于文件和邮件传输，在传输层采用TCP的应用层协议主要有FTP、SMTP、HTTP，另外TCP报文的首部的固定部分为20个字节。
（2）UDP 在传送数据之前不需要先建立连接，不提供可靠交付，传输效率快，以报文形式传输，虽然 UDP 不提供可靠交付，但在QQ 语⾳、 QQ 视频 、直播等即时通信场景中 UDP 却是⼀种最有效的⼯作⽅式。在传输层采用UDP的应用层协议主要有DNS、TFTP、DHCP和SNMP，另外UDP的首部只有8个字节，分别是源端口、目的端口、长度、校验和。

2.4 TCP如何保证可靠传输?

（1）检验和：通过检查校验和，确认在传输过程中没有发生差错。
（2）流量控制：发送方的发送速度太快了，接收方来不及接受，利用滑动窗口来实现流量控制，控制数据发送速度，防止分组丢失。
（3）拥塞控制:根据网络的拥塞程度来调整拥塞窗口的大小，当网络发生拥塞时，减小拥塞窗口的大小，减少数据发送，避免网络负载过大。TCP的拥塞控制采用了四种算法，即 慢开始 、 拥塞避免 、快重传 和 快恢复。 慢开始：发送方刚开始不知道网络的拥塞情况，先试探一下，由小到大的增加拥塞窗口。拥塞避免：缓慢增加拥塞口,每经过一个往返就加一。快重传和快恢复：快速恢复丢失的数据包。避免要求重传时的暂停。
（4）ARQ协议 ：停止等待ARQ：发送端在发送一个分组之后就停止，等待返回来的确认，如果等待一段时间没有收到就重发。连续ARQ：发送方维护一个发送窗口，连续发送窗口的分组，接收方等待最后一个分组发送过来，再发送确认。
（5）超时重传：当 TCP 发出⼀个段后，它启动⼀个定时器，等待⽬的端确认收到这个报⽂段。如果不能及时收到⼀个确认，将重发这个报⽂段。

2.5 UDP如何保证可靠传输？

• UDP是传输层应用，本身是不可靠的，只能在应用层下功夫，模仿TCP的可靠传输，应答确认 （Seq/Ack应答机制），超时重传（定时器），有序传输（将数据包进行编号，按照包的顺序接收并存储）,并且还要实现拥塞控制和可靠传输。
• 开源程序利用udp实现了可靠的数据传输，分别为RUDP、RTP、UDT。
  

2.6 简述TCP粘包现象？

TCP是面向流的协议，发送的单位是字节流，因此会将多个小尺寸数据被封装在一个tcp报文中发出去的可能性。 可以简单的理解成客户端调用了两次send，服务器端一个recv就把信息都读出来了。

2.7 TCP粘包现象处理方法？

固定发送信息长度，或在两个信息之间加入分隔符。

2.8 TCP 的流量控制?

​TCP利⽤滑动窗⼝实现流量控制。流量控制是为了控制发送⽅发送速率，保证接收⽅来得及接收。 接收⽅发送的确认报⽂中的窗⼝字段可以⽤来控制发送⽅窗⼝⼤⼩，从⽽影响发送⽅的发送速率。将窗⼝字段设置为 0，则发送⽅不能发送数据。发送窗口的大小由拥塞窗口和接收窗口的较小值决定。

2.9 TCP 的拥塞控制?

所谓“拥塞”指的是，在某段时间，网络中某一资源的需求超过了该资源能提供的可用部分，使得网络性能发生变化的情况。拥塞控制有四种方法：慢开始、拥塞避免、快重传、快恢复。
为了进行拥塞控制，TCP发送方会维持一个叫拥塞窗口（cwnd）的状态变量。为避免一开始就将大量数据注入网络引起网络拥塞，因此在开始传数据时，使用慢开始算法，它会从小到大的逐渐增大拥塞窗口的数值，cwnd初始值为1，每经过一个轮次，cwnd就加倍；直到cwnd >= sssthresh（设定的窗口阈值），就转而执行拥塞避免算法，每经过一个轮次，cwnd加1；在传输过程中，如果遇到了超时重传，判断网络出现了拥塞，则将ssthresh阈值设定为原来的一半，将拥塞窗口cwnd设置为1，重新开始使用慢开始算法。如果遇到了3-ACK（收到3个重复确认）的情况，则判定分组丢失，使用快重传算法，重传丢失报文，并转而执行快恢复算法， 将ssthresh阈值设定为原来的一半，将拥塞窗口cwnd的值设置为ssthresh阈值，继续执行拥塞避免算法。快重传算法：如果在超时重传定时器溢出之前，接收到连续的三个重复冗余ACK，发送端便知晓哪个报文段在传输过程中丢失了，于是重发该报文段，不需要等待超时重传定时器溢出再发送该报文。

2.10 TCP的长连接和短连接

7.1. TCP短连接
模拟一下TCP短连接的情况：client向server发起连接请求，server接到请求，然后双方建立连接。client向server发送消息，server回应client，然后一次请求就完成了。这时候双方任意都可以发起close操作，不过一般都是client先发起close操作。上述可知，短连接一般只会在 client/server间传递一次请求操作。
短连接的优点是：管理起来比较简单，存在的连接都是有用的连接，不需要额外的控制手段。
7.2. TCP长连接
我们再模拟一下长连接的情况：client向server发起连接，server接受client连接，双方建立连接，client与server完成一次请求后，它们之间的连接并不会主动关闭，后续的读写操作会继续使用这个连接。
7.3. 长连接和短连接的优点和缺点
由上可以看出，长连接可以省去较多的TCP建立和关闭的操作，减少浪费，节约时间。对于频繁请求资源的客户来说，较适用长连接。不过这里存在一个问题，存活功能的探测周期太长，还有就是它只是探测TCP连接的存活，属于比较斯文的做法，遇到恶意的连接时，保活功能就不够使了。在长连接的应用场景下，client端一般不会主动关闭它们之间的连接，Client与server之间的连接如果一直不关闭的话，会存在一个问题，随着客户端连接越来越多，server早晚有扛不住的时候，这时候server端需要采取一些策略，如关闭一些长时间没有读写事件发生的连接，这样可 以避免一些恶意连接导致server端服务受损；如果条件再允许就可以以客户端机器为颗粒度，限制每个客户端的最大长连接数，这样可以完全避免某个蛋疼的客户端连累后端服务。
短连接对于服务器来说管理较为简单，存在的连接都是有用的连接，不需要额外的控制手段。但如果客户请求频繁，将在TCP的建立和关闭操作上浪费时间和带宽。
长连接和短连接的产生在于client和server采取的关闭策略，具体的应用场景采用具体的策略，没有十全十美的选择，只有合适的选择。
7.4. 长连接短连接操作过程
 短连接的操作步骤是：
 建立连接——数据传输——关闭连接...建立连接——数据传输——关闭连接​
 长连接的操作步骤是：
  建立连接——数据传输...（保持连接）...数据传输——关闭连接
7.5. 什么时候用长连接，短连接？
长连接多用于操作频繁，点对点的通讯，而且连接数不能太多情况。每个TCP连接都需要三步握手，这需要时间，如果每个操作都是先连接，再操作的话那么处理速度会降低很多，所以每个操作完后都不断开，次处理时直接发送数据包就OK了，不用建立TCP连接。例如：数据库的连接用长连接， 如果用短连接频繁的通信会造成socket错误，而且频繁的socket 创建也是对资源的浪费。
而像WEB网站的http服务一般都用短链接，因为长连接对于服务端来说会耗费一定的资源，而像WEB网站这么频繁的成千上万甚至上亿客户端的连接用短连接会更省一些资源，如果用长连接，而且同时有成千上万的用户，如果每个用户都占用一个连接的话，那可想而知吧。所以并发量大，但每个用户无需频繁操作情况下需用短连好。

3. HTTP

3.1 地址栏输入URL的过程

总体来说分为以下几个过程:

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

3.2 简述HTTP协议

HTTP协议是超文本传输协议。它是基于TCP协议的应用层协议，即客服端和服务器段进行数据传输的一种规则。HTTP协议本身是一种无状态的协议。

3.3 简述cookie

HTTP协议本身是无状态的，为了使其处理更加复杂的逻辑，在HTTP1.1中引入了Cookie来保存状态信息。Cookie是由服务器端产生的，再发送给客户端保存，当客服端再次访问的时候，服务器根据cookie辨识客户端是那个，以此可以做个性化推送，免账号密码登录等。

3.4 简述session

Session用于标记特定客户端信息，存在服务器的一个文件里。一般客户端带Cookie对服务器进行访问，可以通过cookie中的session id 从整个session中查询服务器记录的关于客户端的信息。

3.5 简述Cookie 和 Session的区别

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

3.6 HTTP1.0 和HTTP1.1的主要区别是什么？

1. ⻓连接 : 在HTTP/1.0中，默认使⽤的是短连接，也就是说每次请求都要重新建⽴⼀次连接。HTTP 是基于TCP/IP协议的,每⼀次建⽴或者断开连接都需要三次握⼿四次挥⼿的开销，如果每次请求都要这样的话，开销会⽐较⼤。因此最好能维持⼀个⻓连接，可以⽤个⻓连接来发多个请求。HTTP 1.1起，默认使⽤⻓连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有⾮流⽔线⽅式和流⽔线⽅式 。流⽔线⽅式是客户在收到HTTP的响应报⽂之前就能接着发送新的请求报⽂。与之相对应的⾮流⽔线⽅式是客户在收到前⼀个响应后才能发送下⼀个请求。
2. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发⽣冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
3. 缓存处理 :在HTTP1.0中主要使⽤header⾥的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引⼊了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match,If-None-Match等更多可供选择的缓存头来控制缓存策略。
4. 带宽优化及⽹络连接的使⽤ :HTTP1.0中，存在⼀些浪费带宽的现象，例如客户端只是需要某个对象的⼀部分，⽽服务器却将整个对象送过来了，并且不⽀持断点续传功能，HTTP1.1则在请求头引⼊了range头域，它允许只请求资源的某个部分，即返回码是206（PartialContent），这样就⽅便了开发者⾃由的选择以便于充分利⽤带宽和连接。
   

3.7 简述http2.0的改进

**提出多路复用**。多路复用前，文件时串行传输的，请求a文件，b文件只能等待，并且连接数过多。引入多路复用，a文件b文件可以**同时传输。 **<br />**引入了二进制数据帧**。其中帧对数据进行顺序标识，有了序列id，服务器就可以进行并行传输数据。

3.8 HTTP 和 HTTPS 的区别,HTTPS是如何实现的？

1. 端⼝ ：HTTP的URL由“http://”起始且默认使⽤端⼝80，⽽HTTPS的URL由“https://”起始且默认使⽤端⼝443。
2. 安全性和资源消耗： HTTP协议运⾏在TCP之上，所有传输的内容都是明⽂，客户端和服务器端都⽆法验证对⽅的身份。HTTPS是运⾏在SSL/TLS之上的HTTP协议，SSL/TLS 运⾏在TCP之上。所有传输的内容都经过加密，加密采⽤对称加密，但对称加密的密钥⽤服务器⽅的证书进⾏了⾮对称加密。所以说，HTTP 安全性没有 HTTPS⾼，但是 HTTPS ⽐HTTP耗费更多服务器资源。
3. ** HTTPS的实现过程（SSL/TLS握手过程）**

• 浏览器将支持的加密算法信息发给服务器
• 服务器选择一套浏览器支持的加密算法，以证书的形式回发给浏览器
• 客户端(SSL/TLS)解析证书验证证书合法性，生成对称加密的密钥，我们将该密钥称之为client key，即客户端密钥，用服务器的公钥对客户端密钥进行非对称加密。
• 客户端会发起HTTPS中的第二个HTTP请求，将加密之后的客户端对称密钥发送给服务器
• 服务器接收到客户端发来的密文之后，会用自己的私钥对其进行非对称解密，解密之后的明文就是客户端密钥，然后用客户端密钥对数据进行对称加密，这样数据就变成了密文。
• 服务器将加密后的密文发送给客户端
• 客户端收到服务器发送来的密文，用客户端密钥对其进行对称解密，得到服务器发送的数据。这样HTTPS中的第二个HTTP请求结束，整个HTTPS传输完成

3.9 服务器返回常见状态码及其意义

• 1XX: 表示接收的信息正在处理
• 2XX: **表示正常处理完毕 **
  • 200 OK //客户端请求成功
• 3XX: 重定向–要完成请求必须进行更进一步的操作
  • 301 永久性重定向，
  • 302 临时性重定向
  • 304：资源没有修改，用之前的缓存就行
• 4XX: 客户端错误–请求有语法错误或请求无法实现
  • 400 Bad Request 客户端请求的报文有误。
  • 401 Unauthorized 请求未经授权。
  • 403 Forbidden 服务器禁止范围资源。
  • 404 Not Found 请求的资源在服务器上不存在或未找到。
• 5XX: 服务器端错误–服务器未能实现合法的请求
  • 500 Internal Server Error 服务器发生不可预期的错误。
  • 502 作为网关或代理请求时，接收到无效的响应。
  • 503 Server Unavailable 服务器短时间内不能处理客户端的请求，待恢复。
    

3.10 常用协议端口号

21:   ftp–文件传输协议（FTP）
 25:   smtp–简单邮件传输协议（SMTP）
 53： dns–域名服务
 80:   http–超文本传输协议
 443： https
 8080：tomcat
 110: pop3–邮局协议版本3

3.11 GET和POST的区别

GET和POST本质上就是TCP连接。一般在使用的时候，get方法将参数放在url中，post将参数放在request body当中。但是他们本质的区别（？并不是这样）：GET产生一个TCP数据包；POST产生两个TCP数据包。
Get方法：把http header和data放在一起发送，服务器返回200.
Post方法：浏览器先发http header，服务器返回100 continue，浏览器再发送data，服务器返回200

3.12 URI和URL的区别是什么？

• URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。
• URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，⽽且还指明了如何 locate 这个资源。
• URI的作⽤像身份证号⼀样，URL的作⽤更像家庭住址⼀样。URL是⼀种具体的URI，它不仅唯⼀标识资源，⽽且还提供了定位该资源的信息。
  

4. ARP协议原理

分两步：

• 本机中缓存的ARP列表中存储了ip mac的 映射关系  查得到则直接得到目标主机的mac地址 查不到转2 。
• 源主机在其本地网段 发送arp请求的广播包  若该网段存在目标主机 则目标主机会回发一个ARP响应包 若收不到arp相应 则说明查找失败 。
  

5. DNS（域名解析协议）

5.1 简述DNS协议

DNS协议是基于UDP的应用层协议，它的功能是根据用户输入的域名，解析出该域名对应的IP地址，从而给客户端进行访问。

5.2 DNS域名解析过程

迭代查询：
① 请求发起后，游览器首先会解析这个域名，首先它会查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。
② 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地DNS(域名分布系统)服务器 。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
③ 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询
④ 根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到那个顶级域服务器上去继续查询，并给出顶级域服务器的地址。这种过程是迭代的过程
⑤ 本地DNS服务器继续向顶级域服务器发出请求，顶级域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你应该去找那个权限域名服务器​
⑥ 最后，本地DNS服务器向权限域名服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问。