1、TCP

（1）介绍一下OSI七层模型和TCP五层模型？

OSI七层模型从上到下依次为：

应用层：为应用程序提供网络服务；

表示层：数据格式转换、数据压缩和数据加密；

会话层：建立、断开和维护通信链接；

传输层：为上层协议提供端到端的可靠传输；

网络层：寻址和路由；

数据链路层：定义通过通信媒介互连的设备之间传输的规范；

物理层：利用物理传输介质为数据链路层提供物理连接。

TCP五层模型相比OSI七层模型，将OSI的应用层、表示层和会话层合为一层：应用层，其他不变。

（2）什么是面向有连接型和面向无连接型？

面向有连接型传输包括会话建立、传输数据和会话断开，此外还包括保证传输可靠性的各种措施，比如超时重传、流量控制等，常见的面向有连接传输有TCP；
面向无连接型传输仅提供基本的传输数据的功能，即使接收端不存在，发送端也能发送数据包，常见的面向无连接传输有UDP、IP。

（3）什么是UDP和TCP？UDP和TCP的区别是什么？

UDP和TCP都是传输层的协议，用来建立可靠的通信传输链接的。

UDP仅提供了最基本的数据传输功能，至于传输时连接的建立和断开、传输可靠性的保证这些UDP统统不关心，而是把这些问题抛给了UDP上层的应用层程序去处理，自己仅提供传输层协议的最基本功能。

TCP作为一种面向有连接的协议，只有在确认通信对端存在时才会发送数据，会在传输开始前建立连接，传输结束后断开连接，此外，TCP还采取了多种措施保障传输的可靠性。

TCP和UDP的区别如下：

TCP是面向有连接型，UDP是面向无连接型；
TCP是一对一传输，UDP支持一对一、一对多、多对一和多对多的交互通信；
TCP是面向字节流的，即把应用层传来的报文看成字节流，将字节流拆分成大小不等的数据块，并添加TCP首部；UDP是面向报文的，对应用层传下来的报文不拆分也不合并，仅添加UDP首部；
TCP支持传输可靠性的多种措施，包括保证包的传输顺序、重发机制、流量控制和拥塞控制；UDP仅提供最基本的数据传输能力。

（4）TCP对应的应用层协议有哪些？UDP对应的应用层协议有哪些？

TCP对应的典型的应用层协议：

FTP：文件传输协议；
SSH：远程登录协议；
HTTP：web服务器传输超文本到本地浏览器的超文本传输协议。

UDP对应的典型的应用层协议：

DNS：域名解析协议；
TFTP：简单文件传输协议；
SNMP：简单网络管理协议。

（5）介绍一下TCP三次握手？为什么不是两次？为什么不是四次？

三次握手

物理层、数据链路层在物理层面上架设好了通信链路，网络层确定了通信双方的地址，那下一步就是传输层建立逻辑层面上的通信连接，将从应用层获得的报文数据从源端发送给接受端。TCP的三次握手就是在发送数据前通过“三次握手”的方式建立起这个通信连接，建立这个连接的目的是让源端和目的端确认一下双方的发送报文能力和接收报文能力是正常的，实际上就是通过三次握手这个操作将下面的表填完整：

图1.1 三次握手要填充的表格

下面具体介绍三次握手的过程，并在每次握手时填充这个表格，当表格填满后，意味着源端和目的端已确认完毕双方的发送报文能力和接收报文能力是正常的，三次握手结束，通信双方的连接已成功建立。

TCP报文首部

在介绍三次握手前先介绍一下TCP报文的首部，报文首部可以理解为报文的元数据，里面存放着与这次报文相关的其他信息，图我就不摆了，介绍一下跟三次握手相关的报文首部字段。

（1）序号seq

对字节流的编号。例如第一个字节的序号为 301，如果携带的数据长度为 100 字节，那么下一个报文段的序号应为 401。注意第一份报文段的序号是随机生成的，后面的报文段序号是根据上一个报文段序号及报文长度生成的。

（2）确认号ack

期望收到的下一个报文段的序号。例如 B 正确收到 A 发送来的一个报文段，序号为 501，携带的数据长度为 200 字节，因此 B 期望下一个报文段的序号为 701，B 发送给 A 的确认报文段中确认号就为 701。

（3）SYN

控制位的一种，用于建立连接，该位设为 1，表示希望建立连接，并对第一份报文的序号进行随机初始化。

（4）ACK

控制位的一种，确认应答的字段有效，TCP规定除了最初建立连接时的 SYN 包以外该位必须设为 1。

（5）FIN

控制位的一种，当FIN=1，表明此报文的发送方的数据已经发送完毕，要求关闭连接。

三次握手具体过程

TCP三次握手的过程如图所示

TCP三次握手过程

（1）第一次握手

Client端将SYN置为1，表示希望与Server端建立连接；序号seq初始化为J，并将该数据包发送给Server端，Client进入SYN_SENT状态，等待Server确认。

（2）第二次握手

Server端检查报文发现SYN为1，知道了Client端想建立连接；Server端将SYN置为1，表示Server端也希望与Clinet端建立连接；Server端将ACK置为1，表示收到了Client端建立连接的请求；Server端将seq初始化为K；Server端将ack置为J+1，这里ack=seq + 1，还有疑问（如果控制位占1字节，为什么第三次握手时有ACK=1、SYN=1，ack为什么不是+2？如果+1只是告诉服务端收到了消息，那ACK控制位就已经达到目的了，为什么还要多次一举再加一个ack?）。第二次握手包括服务端确认客户端发来的报文和服务端向客户端发送报文两个过程。

第二次握手时表格填充结果如下：

第二次握手表格填充

（3）第三次握手

Client收到报文后，检查ack是否为J+1，ACK是否为1，如果正确则将标志位ACK置为1，ack=K+1，并将该数据包发送给Server，Server检查ack是否为K+1，ACK是否为1，如果正确则连接建立成功，Client和Server进入ESTABLISHED状态，完成三次握手，随后Client与Server之间可以开始传输数据了。第三次握手包括客户端确认服务端发来的报文，客户端向服务端发送报文和服务端确认客户端发来的报文三个过程。

第三次握手客户端确认信息后填充表格如下:

第三次握手客户端确认信息表格填充

第三次握手服务端确认信息后填充表格如下：

第三次握手服务端确认信息表格填充

至此，表格填充完毕，三次握手也结束，连接成功建立。有些面试官会问为什么不是2次握手？

因为2次握手表格填充不完，源端和目的端无法确认双方的收发能力；为什么不是4次握手？3次握手表格就填充完毕了，不需要再多一次握手了。

（6）介绍一下TCP四次挥手？为什么不是三次？为什么不是五次？

四次挥手

三次握手是建立TCP连接，四次挥手是断开TCP连接，即客户端和服务端总共要收发4个包才能确定断开连接。

四次挥手的具体过程

四次挥手的过程如图所示：

TCP四次挥手过程图

（1）第一次挥手

假设客户端主动发起断开请求，客户端向服务端发送报文，报文首部包括FIN=1，这个控制位代表客户端想要断开连接；序列号seq=u，这时客户端进入FIN-WAIT-1（终止等待1）状态，停止发送数据，并等待服务端的确认。

（2）第二次挥手

服务端收到客户端的报文后发出确认报文，控制位ACK=1；确认号ack=u+1；序列号seq=v；然后服务端就进入CLOSE-WAIT（关闭等待）状态。TCP服务端会告知上层的应用进程来自客户端的连接即将关闭，让应用程序做好相应的准备。此时客户端已经没有数据向服务端发送了，但服务端向客户端发送数据，客户端依然能接收。

（3）第三次挥手

客户端收到服务器确认报文后，进入FIN-WAIT-2状态。此时服务器再次发送报文，报文首部控制位FIN=1，表示服务端向客户端发送断开连接请求；确认标志ACK=1；确认序号ack=u+1；序号seq=w，然后服务器进入LAST-ACK（最后确认态），等待客户端确认。

（4）第四次挥手

客户端收到了服务端的断开连接的报文后，必须发出确认报文，标志位ACK=1；确认号ack=w+1;序号seq=u+1；之后客户端就进入了TIME-WAIT（时间等待）状态。注意此时客户端的TCP连接还没有释放，必须经过2*MSL（最长报文段寿命）的时间后，客户端才进入CLOSED状态关闭连接。而服务端只要收到了客户端发送的确认报文后就会进入CLOSED状态关闭服务端连接。当客户端和服务端都进入了CLOSED状态后，客户端和服务端之间的连接才完全断开。

2.2 为什么会有TIME_WAIT状态？

上面介绍第四次挥手的过程中，客户端在发送完给服务端的回执报文后没有立刻进入CLOSED状态，而是进入TIME-WAIT状态，然后等待2*MSL（最长报文段寿命）的时间后才进入CLOSED状态，这是为什么？原因有以下两点：

客户端发送给服务端回执后，有可能这个回执报文在传输途中丢失等原因，服务端并没有收到，此时服务端会再次向客户端发送FIN=1的断开请求报文，如果客户端没有等待2*MSL时间而直接进入了CLOSED状态，客户端就会收不到服务端再次发送的断开连接的请求报文，导致服务端无法进入CLOSED状态；
等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

注：MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

2.3 为什么是四次挥手而不是三次或者五次？

第二次挥手和第三次挥手都是服务端向客户端发送报文，第二次挥手是服务端收到了客户端的断开请求，通知客户端俺收到了，此时客户端没有数据向服务端发送了，但不代表服务端也没有数据向客户端发送，因为服务端要把剩余还没有发送的报文发送完毕再断开连接；第三次挥手是服务端数据全部发送完毕，向客户端发送断开请求报文（FIN=1）。

如果是三次挥手，即把服务端向客户端发送报文的第二次挥手和第三次挥手合为一次，会造成服务端发送了回执后立刻又发送断开请求，造成服务端有数据没有全部发送至客户端，因此必须将第二次挥手和第三次挥手分开；五次挥手则完全没必要，多此一举。

（7）在四次挥手中，为什么客户端进入TIME_WAIT状态等待2*MSL时间，而不是直接进入CLOSED状态？

客户端在发送完给服务端的回执报文后没有立刻进入CLOSED状态，而是进入TIME-WAIT状态，然后等待2*MSL（最长报文段寿命）的时间后才进入CLOSED状态，这是为什么？原因有以下两点：

客户端发送给服务端回执后，有可能这个回执报文在传输途中丢失等原因，服务端并没有收到，此时服务端会再次向客户端发送FIN=1的断开请求报文，如果客户端没有等待2*MSL时间而直接进入了CLOSED状态，客户端就会收不到服务端再次发送的断开连接的请求报文，导致服务端无法进入CLOSED状态；
等待一段时间是为了让本连接持续时间内所产生的所有报文都从网络中消失，使得下一个新的连接不会出现旧的连接请求报文。

注：MSL是Maximum Segment Lifetime英文的缩写，中文可以译为“报文最大生存时间”，他是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。

（8）说一下ARQ协议？

ARQ协议，即自动重传请求（Automatic Repeat-reQuest），意思是如果发送方在发送后一段时间之内没有收到确认回执，它通常会重新发送。ARQ协议包括停止等待ARQ协议和连续ARQ协议。

（1）停止等待ARQ协议

停止等待ARQ协议是指，在停止等待中如果接收端没有收到发送端发来的分组，接收端就不会给发送端发送确认回执，此时发送端会重新发送之前的报文分组。发送端会维护一个超时计时器，超时时间会设置的比数据在传输往返过程的时间要长一些。

（2）连续ARQ协议

连续ARQ协议是指，发送端维护一个“窗口”，“窗口”内可以有多个分组，窗口的大小就是窗口中分组的个数，凡是位于“窗口”内的分组可以连续发送出去而不必等待接收端返回的确认回执，对按序到达的最后一个分组，接收端会向发送端发送确认回执，如果有分组没有正确到达，会返回最后一个正确达到的分组序号，该序号后面的分组会重新发送给接收端。

举个例子，窗口大小为4，发送时第1、2、4号分组均成功发送，3号分组发送失败，接收端会给发送端发送2号分组的确认回执，然后发送端会把2号分组之后的数据（3号分组和4号分组）重新再发送一遍，即使4号分组是发送成功的。

在连续ARQ协议中，发送端会维护一块发送端的数据缓存，“窗口”里的分组都会在这个缓存中，当需要重新发送“窗口”中的分组报文时，便会从缓存里读取分组并发送。

连续 ARQ 协议可提高信道利用率。

（9）说一下TCP的流量控制？

流量控制是为了控制发送端发送数据的速率，保证接收端能将本应接收的所有报文分组接收成功，否则会触发自动重传机制造成网络流量的浪费。

流量控制的具体操作是：接收端会通知发送端自己能接收的数据大小，于是发送端会发送不超过这个数据量的数据，这个大小被称为“窗口”的大小，在TCP首部中专门有一个字段表示“窗口”的大小，该值越大代表网络的吞吐量越高。

（10）说一下TCP的拥塞控制？

计算机网络都处在一个共享的环境，在通信开始时如果立即把大量数据注入到网络，可能会引起网络阻塞，甚至带来网络瘫痪。TCP为了防止该问题的出现，采用了拥塞控制的策略，常见的拥塞控制策略有慢启动、拥塞避免、快重传与快恢复，这里以慢启动为例做简单介绍。

在通信开始时，定义一个“拥塞窗口”，窗口大小为1，意思是开始时只发送一个分组，之后每收到一个确认回执（ACK），拥塞窗口的大小就加1（即逐渐增大窗口大小），发送端在发送数据时，将拥塞窗口的大小与接收端流量控制窗口的大小作比较，取二者中较小的值，然后实际发送的数据量比这个最小值还要小。

（11）什么是TCP粘包？

如果客户端连续不断的向服务端发送数据包时，服务端接收的数据会出现两个数据包粘在一起的情况。

\1. TCP 是基于字节流的，虽然应用层和 TCP 传输层之间的数据交互是大小不等的数据块，但是 TCP 把这些数据块仅仅看成一连串无结构的字节流，没有边界；

\2. 从 TCP 的帧结构也可以看出，在 TCP 的首部没有表示数据长度的字段。

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

（12）粘包是如何产生的？

（1）发送方产生粘包

采用 TCP 协议传输数据的客户端与服务器经常是保持一个长连接的状态（一次连接发一次数据不存在粘包），双方在连接不断开的情况下，可以一直传输数据。但当发送的数据包过于的小时，那么 TCP 协议默认的会启用 Nagle 算法，将这些较小的数据包进行合并发送（缓冲区数据发送是一个堆压的过程）；这个合并过程就是在发送缓冲区中进行的，也就是说数据发送出来它已经是粘包的状态了。

一句话：要发送的数据小于 TCP 发送缓冲区的大小，TCP 将多次写入缓冲区的数据一次发送出去，将会发生粘包。

（2）接收方产生粘包

接收方采用 TCP 协议接收数据时的过程是这样的：数据到接收方，从网络模型的下方传递至传输层，传输层的 TCP 协议处理是将其放置接收缓冲区，然后由应用层来主动获取（C 语言用 recv、read 等函数）；这时会出现一个问题，就是我们在程序中调用的读取数据函数不能及时的把缓冲区中的数据拿出来，而下一个数据又到来并有一部分放入的缓冲区末尾，等我们读取数据时就是一个粘包。（放数据的速度 > 应用层拿数据速度）。

一句话：接收数据端的应用层没有及时读取接收缓冲区中的数据，将发生粘包。

（13）如何避免粘包？

有以下两个措施：

在每个包的末尾加上特殊字符，用以区分连续的两个包；
在报文首部添加包的长度。

2、http

（1）什么是http协议？http和https的区别？

http协议是应用层的协议，中文名称是超文本传输协议，是客户端和服务端相互通信时将信息以http报文的形式传输。

https可以简单的理解为：https = http + 加密 + 认证 + 完整性保护。

http协议的缺点:

通信使用明文，内容可能被窃听。
通信双方的身份无法得到认证，身份可能遭遇伪装。
无法验证报文的完整性。

针对以上问题，https的改进措施:

加密。https协议通过SSL或者TLS协议将报文内容进行加密，client端进行加密，server端进行解密。
认证。通过值得信赖的第三方机构颁布证书，即可确认通信双方的身份。客户端持有证书即可完成客户端身份的确认，客户端通信前会查看服务端的证书。
完整性保护。可以通过MD5等散列码进行通信内容的校验。

（2）为什么说http协议是无状态协议？怎么解决Http协议无状态协议?

http协议是一种无状态协议，协议自身不对请求和响应之间的通信状态进行保存，即对发送过来的请求和响应都不做持久化处理，把http协议设计的如此简单是为了更快地处理大量事务。

为了解决http协议不能保存通信状态的问题，引入了Cookie状态管理。Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。Cookie会根据从服务端发送的响应报文的一个叫Set-Cookie的首部字段，通知客户端保存Cookie。当下次客户端再往该服务端发送请求时，客户端会自动在请求报文中加入Cookie值发送出去，服务端发现客户端发来的Cookie后，会检查是哪一个客户端发来的连接请求，对比服务器上的记录，最后得到之前的状态信息。

（3）URI和URL的区别?

URI: Uniform Resource Identifier，统一资源标识符，用来唯一标识互联网中的一份资源。

URL: Uniform Resource Locator，统一资源定位符，我们访问网站的网址就是URL。

URL是URI的子集。

URI的目的就是唯一标识互联网中的一份资源，具体可以用资源名称、资源地址等，但是资源地址是目前使用最广泛的，因此URL就容易和URI混淆。URI相当于抽象类，URL就是这个抽象类的具体实现类。

（4）常见的http动词有哪些？

GET: 从服务器获取资源
POST: 在服务器新建资源
PUT: 在服务器更新资源
DELETE: 在服务器删除资源
HEAD: 获取资源的元数据
OPTIONAL: 查询对指定的资源支持的方法

（5）put和post的区别？

put是幂等的，post不是。

幂等是数学的一个用语，对于单个输入或者无输入的运算方法，如果每次都是同样的结果，则称其是幂等的。也就是说，如果一个网络重复执行多次，产生的效果是一样的，那就是幂等（idempotent）。

post在发请求的时候，服务器会每次都创建一个文件，而put发请求的时候，是更新文件而不是创建文件，因此put是幂等的。

（6）http请求报文和响应报文的组成？

http协议全称是HyperTest Transfer Protocol，超文本传输协议。

http报文说白了就是client和server通信时依据http协议，将传输的信息以文本的形式呈现，这个文本就是http报文。http报文分为请求报文和消息报文，这两类报文有着相同的结构组成，如图：

http报文组成

网上有很多如何在浏览器上查看http报文的，我这里举个例子，方便理解。

http请求报文：

http请求报文

http响应报文：

http响应报文

图中没有显示空行和报文主体。

下面大致讲一下这四部分：

请求行/响应行

请求行由http动词，请求uri和http版本组成，主要是反应这次请求要对什么资源做什么操作

响应行由http返回码，原因短语和http版本组成，呈现的服务端对这次请求的处理结果，我们通过响应行的信息能知道这次请求是否成功，bug出在client端还是server端，原因是什么。

首部字段

首部字段又叫头域（header），相当于http报文的元数据，记录了这次http报文的具体描述信息，比如时间、服务端域名等。

空行

用来区分首部字段和报文主体。

报文主体

报文主体并不是每个报文都有的，要看具体的报文是要做什么，比如列举桶的返回报文里，报文主体会把桶列表以xml格式返回，但是列举桶的请求报文主体什么都不包含。报文主体返回的格式一般是xml或者json格式。

（7）常见的http返回码有哪些？

200：请求被正常处理
204：请求被受理但没有资源可以返回
206：客户端只是请求资源的一部分，服务器只对请求的部分资源执行GET方法，相应报文中通过Content-Range指定范围的资源。
301：永久性重定向
302：临时重定向
303：与302状态码有相似功能，只是它希望客户端在请求一个URI的时候，能通过GET方法重定向到另一个URI上
304：发送附带条件的请求时，条件不满足时返回，与重定向无关
307：临时重定向，与302类似，只是强制要求使用POST方法
400：请求报文语法有误，服务器无法识别
401：请求需要认证
403：请求的对应资源禁止被访问
404：服务器无法找到对应资源
500：服务器内部错误
503：服务器正忙