计算机网络面试

OSI“实现”：TCP/IP

在这里插入图片描述
OSI模型注重通信协议必要的功能是什么，而TCP/IP则更强调在计算机上实现协议应该开发哪种程序。

在这里插入图片描述

TCP三次握手

URG：紧急指针标志
ACK：确认序号标志
为1时表示确认号有效，为0表示报文中不含确认信息，忽略确认号字段，上面的确认号是否有效就是通过该标识位控制的
PSH：push标志
RST：重置连接标志
SYN：同步序号，用于建立连接过程
在连接请求中，SYN = 1 与 ACK = 0 表示该数据段没有使用捎带的确认阈，而连接应答捎带一个确认即 SYN = 1 ，ACK = 1
FIN：用于释放连接
为1时表示发送方已经没有数据发送了，即关闭奔放数据流。

“握手”是为了建立连接，而连接的目的是形成虚拟电路

在这里插入图片描述
简要阐述：

详细阐述：
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。

最开始，客户端与服务器都处于CLOSED的状态。假设主动打开连接的是客户端，被动打开连接的是服务器，刚开始的时候TCP服务器进程先创建传输控制块TCB，时刻准备接收其他客户进程发送过来的连接请求，此时服务器进入LISTEN即监听状态，这时客户端也是先创建一个传输控制块TCB，然后向服务器发出连接请求报文，SYN = 1，同时选择一个初始序号seq = x，这个x可以是一个任意的正整数值，此时TCP客户端进程进入了SYN-SENT 同步已发送状态，此时发送过去的数据包即报文段会被称为SYN报文段，它是不能携带数据的，但是要消耗掉一个序号，这便是第一次握手。
当服务器接收到请求报文后，如果同意连接，则发出确认报文。确认报文中包含了ACK = 1和SYN = 1，确认号就是x+1（原因是在之前的SYN报文中指定了sequence number = x，作为回应，回应跟x相关的信息，并且由于上面的报文消耗掉了一个序号，因此它就成为x+1），同时也要为自己的缓存初始化一个序列号即seq = y，此时服务器进入到了SYN-RCVD 同步收到状态，这个报文也是不能携带数据的，并且同样需要消耗一个序号，这便是第二次握手。
当TCP客户进程收到确认报文之后，还要向服务器给出一个确认，确认报文的ACK = 1，小的ack = y+1（原因是因为服务器刚刚发了seq= y，同时该报文也要消耗一个序号，作为回应就给了y+1），同时先前告知了序号被+1了，因此这里seq = x+1，此时TCP连接建立，客户端就进入了ESRABLISHED已建立连接状态，而TCP规定这个报文段可以携带数据，前两个都是不可以携带的，当然它也可以不携带，如果不携带数据就不会消耗序号，这便是第三次握手。当服务器收到客户端的确认后也会进入ESRABLISHED的状态，此后双方就可以开始通信了。

为什么需要三次握手才能建立起连接

主要是为了初始化Sequence Number的初始值。通信的双方要互相通知对方自己初始化的Sequence Number，也就是x，y，这个号要作为以后数据通信的序号，以保证应用层接收到的数据不会因为网络上的传输问题而乱序，即TCP会用这个序号来拼接数据。因此，在服务器回发它的Sequence Number即第二次握手之后还需要发送确认报文给服务器，告知服务器说客户端已经收到你的初始化的Sequence Number了。

首次握手的隐患—SYN超时

如果服务器接收到了客户端发送的SYN后，回复SYN-ACK，回复后客户端就掉线了，此时服务器就没有收到客户端发送回来的ACK包的确认，那么这个链接就会处于一个中间状态，既没有成功也没有失败，于是服务器如果在一定时间内没有收到客户端的回执，那么它就会重发SYN-ACK，在Linux下默认重试次数为5次，重试的间隔时间从1秒开始，每次都翻倍，也就是1，2，4，8，16，总共31秒，在第5次发出去后还需要等待32秒才能够被判定为超时，所以共需63秒TCP才会断开这个连接，可能就会造成服务器SYN Flood攻击的风险。恶意程序会给服务器发一个SYN报文，发了后就下线，于是服务器默认等63秒才会断开连接，这个攻击者就可以把服务器的SYN连接的队列耗尽，让正常的连接请求不能处理，于是Linux下就给了一个tcp-syncookies的参数来应对这个事情。当SYN队列满了之后TCP会通过源地址端口、目标地址端口和时间戳打造出一个特别的Sequence Number发回去，这个Sequence Number简称为SYN Cookie。如果是攻击者是不会有响应的，如果是正常连接就会把这个syncooky发回来，然后服务器可以通过Cookie建立连接。通过SYN Cookie即便此时SYN队列满了，本次连接请求不在队列中，依然能够建立连接，就能解决该问题的发生。

建立连接后，客户端出现故障怎么办

TCP设有保活机制。在一段时间，称为保活时间。在这段时间内连接处于非活动状态，开启保活功能的一端将向对方发送一个保活探测报文，如果发送端没有收到响应报文，那么经过一个已经提前配好的保活时间间隔，将继续发送保活探测报文，直到发送探测报文的次数达到保活探测数，这时对方主机将被确认为不可达，连接也将被中断。

TCP的四次挥手

“挥手”是为了终止连接，TCP四次挥手的流程图如下：
在这里插入图片描述
数据传送完毕之后，双方都可释放连接，最开始客户端和服务器都处于ESTABLISHED的状态，假设客户端主动关闭，服务器被动关闭。
简要阐述：

详细阐述：

第一次挥手： 首先客户端进程发出连接释放报文并且停止发送数据，在该数据报的报头中，TCP Flag中的FIN = 1，这里假设客户端定义的序列号为seq = u，该值等于之前ESTABLISHED状态下数据最后一次发送时已经传送过来的数据的最后一个字节的序号+1，此时客户端进入了FINISH_WAIT_1终止等待状态。
第二次挥手： 当服务器收到连接释放报文后也要发出确认报文即ACK = 1，作为回应ack = u+1（TCP规定，即使SYN报文段不想携带任何数据也要消耗掉一个序号，即回执的时候u+1），并且也携带了自己的序列号seq = v，此时服务器进入了CLOSE_WAIT关闭等待状态。
第三次挥手： TCP服务器通知高层的应用进程，客户端要释放跟服务器通信的连接，这时会处于半关闭状态，即客户端已经没有数据要发送了，但是服务器若要发送数据客户端还是能够接收的，这个状态还要持续一段时间，该时间等于整个CLOSE位状态所持续的时间，那客户端收到服务器的确认请求后，也就是第二次挥手时客户端就进入了FINISH_WAIT-2终止等待2状态，等待服务器发送释放连接报文，也就是等待服务器第三次挥手请求，因此在这段时间内，客户端有可能接收服务器发送的最后数据，服务器将最后的数据发送完毕后就会向客户端发送释放连接报文，这里FIN = 1，ack = u+1，由于在半关闭状态，服务器很可能又发送了一些数据，所以假定此时的序号变为seq = w，这时服务器进入了LAST_ACK最后确认状态，等待客户端的最后确认。
第四次挥手： 客户端在收到服务器的连接释放报文后必须发出确认，即ACK = 1，再将服务器发过来的w变成w+1，通过ack回发到服务器，自己序号为seq = u+1，此时客户端进入了TIME_WAIT时间等待状态，注意此时客户端的TCP连接还没有释放，必须经过2×MSL的时间，连接才会真正的释放，才进入到CLOSED的状态。（MSL是最长报文段寿命，IFC定义2分钟，Linux下是30秒）。服务器一收到客户端发送的确认，立即就进入CLOSE的状态，可以看到服务器结束TCP连接的时间比客户端稍早一些。

为什么会有TIME_WAIT状态

TIME_WAIT状态是用来保证有足够的时间让对端来收到ACK，如果被动关闭的那方没有收到ack就会出发被动端重发FIN包，一来一去正好是两个MSL。
有足够的时间让这个连接不会和后面的连接混在一起，因为有些路由器会缓存IP数据包，如果连接被重入，那么这些延迟收到的包就有可能跟新连接混在一起。

为什么需要四次挥手才能断开连接

因为TCP是全双工的，发送方和接收方都需要FIN报文和ACK报文，也就是说发送方和接收方各只需两次挥手即可，只不过有一方是被动的，所以看上去就成了四次挥手。

服务器出现大量CLOSE_WAIT状态的原因

在对方关闭连接后，程序本身没有检测到，或者说程序忘了关闭连接，于是这个资源就一直被程序占用着，遇到这种情况多数是程序里有bug，通常是某些连接没有及时释放导致的，或者某些配置如线程池中的某些线程配置不合理，此时就需要我们结合实际的业务排查了。

TCP特点

TCP通过检验和、序列号、确认应答、重发机制、连接管理以及窗口控制等机制实现可靠传输。

UDP特点

面向非连接
传输数据前，源端和终端不建立连接。当它想传送时，就简单的去抓取来自应用程序的数据并尽可能快的把它扔到网络上。在发送端UDP传输数据的速度仅仅是受应用程序生成数据的速度，计算机的能力，和传输带宽的限制。在接收端UDP把每个消息段放在队列中，应用程序每次从消息队列中读取一个消息段。
不维护连接状态，支持同时向多个客户端传输相同的消息
由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务器可以同时向多台客户机传输相同的消息。
数据包报头只有8个字节，额外开销较小
UDP信息包的报头很短，只有8个字节，相对于TCP包的20个字节的额外开销小很多
吞吐量只受限于数据生成速率、传输速率以及机器性能
吞吐量不受拥挤控制算法的调节，只受应用软件生成的速率、传输带宽，源端和终端主机性能的限制
UDP尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表
面向报文，不对应用程序提交的报文信息进行拆分或合并
UDP是面向报文的，发送方的UDP对应用程序交下来的报文在添加守护后，就向下交付给IP层，既不拆分也不合并而是保留这些报文的边界，因此应用程序需要选择合适的报文大小，也就是说UDP将检阅到的控制交由上层去解决

TCP和UDP的区别

在这里插入图片描述

HTTP主要特点

支持客户/服务器模式
HTTP工作于客户端与服务端架构之上，浏览器作为HTTP客户端通过url向HTTP服务端即Web服务器发送所有请求，Web服务器根据接收到的请求向客户端发送响应信息
简单快速
客户端向服务器请求服务时只需传送请求方法和路径，请求方法常用的有get、post，每种方法规定了客户端与服务器联系的不同。由于HTTP协议简单，使得HTTP服务器的规模小，因而通信速度很快
灵活
HTTP允许传输任意类型的数据对象，正在传送的类型由Content_Type进行标记
无连接
无连接的含义是限制每次连接只处理一个请求，服务器处理完客户的请求并收到客户的应答后就断开连接，采用这种方式可以节省传输时间
无状态
HTTP协议是无状态协议，无状态是指协议对于事物处理没有记忆能力，缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要以前信息时，它的应答就较快

请你说一下HTTP的报文段是什么样的？（请求报文和响应报文）

在这里插入图片描述

请求方法
GET：请求获取Request——URL所标识的资源
POST：在Request——URL所标识的资源后附加资源
HEAD：请求获取由Request——URL所标识的资源的响应消息报头
PUT：请求服务器存储一个资源，由Request——URL作为其标识
DELETE：请求服务器删除由Request——URL所标识的资源
TRACE：请求服务器回送收到的请求信息（用于测试和诊断）
CONNECT：保留
OPTIONS：请求查询服务器性能
URL
URI全名为Uniform Resource Indentifier（统一资源标识），用来唯一的标识一个资源，是一个通用的概念，URI由两个主要的子集URL和URN组成。URL全名为Uniform Resource Locator（统一资源定位），通过描述资源的位置来标识资源。URN全名为Uniform Resource Name（统一资源命名），通过资源的名字来标识资源，与其所处的位置无关，这样即使资源的位置发生变动，其URN也不会变化。
协议版本
格式为HTTP/主版本号.次版本号，常用为：HTTP/1.1 HTTP/1.0
请求头部
Host：接受请求的服务器地址，可以是IP或者是域名
User-Agent：发送请求的应用名称
Connection：指定与连接相关的属性，例如（Keep_Alive，长连接）
Accept-Charset：通知服务器端可以发送的编码格式
Accept-Encoding：通知服务器端可以发送的数据压缩格式
Accept-Language：通知服务器端可以发送的语言

在这里插入图片描述

协议版本，同请求报文
状态码
100-199 表示请求已收到继续处理，200-299 表示成功，300-399 表示资源重定向，400-499 表示客户端请求出错，500-599表示服务器端出错；常见状态码如下：
200：响应成功
302：跳转，重定向
400：客户端有语法错误
401：请求未经授权，这个状态码必须和WWW-Authenticate 报头域一起使用
403：服务器拒绝提供服务
404：请求资源不存在，eg，输入错误的URL
500：服务器内部错误
503：服务器当前不能处理客户端的请求，一段时间后可能恢复正常
响应头部
Server：服务器应用软件的名称和版本
Content-Type：响应正文的类型
Content-Length：响应正文的长度
Content-Charset：响应正文所使用的编码
Content-Encoding：响应正文使用的数据压缩格式
Content-Language：响应正文使用的语言

GET方式和POST方式的区别

HTTP 定义了 与服务器交互 的不同方法，最基本的方法有4种，分别是 GET，POST，PUT，DELETE。URL全称是资源描述符，我们可以这样认为：一个URL地址，它用于描述一个网络上的资源，而HTTP中的GET，POST，PUT，DELETE就对应着对这个资源的 查，改，增，删 4个操作。GET一般用于 获取/查询 资源信息，而POST一般用于更新资源信息。
在这里插入图片描述

对请求参数的处理方式不同（直观的区别）
①GET请求：请求的数据会附加在URL之后，以“？”分隔URL和传输数据，如有多个参数则用“&”连接。URL采用的是ASCII编码方式，而不是Unicode编码格式，即所有的非ASCII字符都要在编码之后再传输。
②POST请求：POST请求会把请求的数据放置在HTTP请求包的Body数据中，数据包的形式可以是“参数名1=参数值1 & 参数名2=参数值2”，也可以是JSON格式（键值对）。当然JSON格式是一种通用的方式。
传输数据的大小不同
HTTP没有对传输数据的大小进行限制，也没有对URL的长度进行限制。而在实际程序开发中，存在以下限制。
①GET：特定浏览器和服务器对URL的长度有限制。例如，IE对URL长度的限制是2083Byte（2×1024Byte+35Byte）。其他浏览器（如Netscape、FireFox等）在理论上没有长度的限制，其限制取决于操作系统的支持。因此，在采用GET方式提交数据时，传输数据会受到URL长度限制。
②POST：由于不是通过URL传值，在理论上数据的大小不受限制。但实际上，各个Web服务器会对采用POST方式提交的数据大小进行限制，例如，Apache、IIS6都有各自的配置。
安全性不同
POST方式的安全性比GET方式的安全性高。使用GET方式时，在地址栏里可以直接看到请求数据，采用这种方式可能受到Cross-site request forgery攻击。
POST方式需要抓包才能获取到数据，变相地提高了安全性。
Ⅲ.Headers和Body

请你回答一下HTTP用的什么连接？

在HTTP/1.0中，默认使用的是 短连接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的 Web页中包含有其他的Web资源，如JavaScript文件、图像文件、CSS文件等；当浏览器每遇到这样一个Web资源，就会建立一个HTTP会话。
但从HTTP/1.1起，默认使用 长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头有加入这行代码：Connection:keep-alive
在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。

HTTP请求/响应的步骤

客户端连接到Web服务器
一个HTTP客户端通常是浏览器与Web服务器的HTTP端口，默认端口号是80，建立一个TCP套接字连接
发送HTTP请求
通过TCP套接字，客户端向Web服务器发送一个文本的请求报文
服务器接受请求并返回HTTP响应
Web服务器解析该请求，定位请求资源，服务器将请求资源副本写到TCP套接字由客户端读取
释放TCP连接
若我们的连接模式为CLOSE，则服务器主动关闭TCP连接，客户端被动关闭连接，释放TCP连接；若连接模式为Keep-Alive，则该连接会保持一段时间，在该时间内可以继续接收请求
客户端浏览器解析HTML内容
客户端浏览器首先去解析状态行，查看表名请求是否成功的状态代代码，然后解析每一个响应头，响应头告知以下为若干字节的HTML文档和文档的字符集，客户端浏览器读取响应数据HTML根据HTML的语法对类型进行格式化，并在浏览器窗口中显示

在浏览器地址栏键入URL，按下回车之后经历的流程

DNS解析
首先浏览器会依据URL逐层查询DNS服务器缓存，解析URL中的域名所对应的IP地址，DNS缓存从近到远依次是浏览器缓存、系统缓存、路由器缓存、IPS服务器缓存、根域名服务器缓存、顶级域名服务器缓存，从哪个缓存找到对应的IP，则直接返回，不再查询后面的缓存
TCP连接
找到IP地址后，会根据IP地址和对应端口（默认80）和服务器建立TCP连接，（可以接着进行三次握手阐述）
发送HTTP请求
浏览器会发出读取文件的HTTP请求，该请求将发送给服务器
服务器处理请求并返回HTTP报文
紧接着服务器对浏览器做出响应，并把对应的带有HTTP文本的HTTP响应报文发送给浏览器，
浏览器收到了HTML并在显示窗口内渲染
连接结束，浏览器释放TCP连接，该步骤就是四次挥手

HTTP和HTTPS的区别

在这里插入图片描述

HTTPS数据传输流程

HTTPS在进行数据传输之前，会与网站服务器和Web浏览器进行一次握手，在握手时确定双方的加密密码信息，具体过程如下：

浏览器将支持的加密算法信息发送给服务器
比如本地仅支持aes对称加密ecc非对称加密之类的，也就是告诉服务器我就支持这类加密，回发时尽量按照这种方式来
服务器选择一套浏览器支持的加密算法，将验证身份的信息以证书的形式回发浏览器
浏览器验证整数合法性，并结合整数公钥加密信息发送给服务器
服务器使用私钥解密信息，验证哈希，加密响应消息回发浏览器

区别

HTTPS需要到CA申请证书，HTTP不需要
一般免费证书较少，因而需要一定的费用
HTTPS密文传输，HTTP明文传输
HTTP是超文本传输协议，信息是明文传输的；而HTTPS是具有安全性的SSL加密传输协议，因此是密文传输的
连接方式不同，HTTPS默认使用443端口，HTTP使用80端口
HTTPS=HTTP+加密+认证+完整性保护，较HTTP安全

HTTPS真的很安全么

那倒未必

用户习惯访问某个网站只会输入域名，例如“www.baidu.com”，而浏览器会自动填充http://，一般网上管理员会由301或302的方式跳转到https，但是这个过程中会使用到http，经过http转发到https，因此很容易引发劫持，受到第三方攻击
这时就可以使用HSTS（HTTP严格安全传输）优化
由于HSTS目前正在推行中，并未成为主流