计算机网络

浏览器输入URL到返回页面的全过程

当输入url时，浏览器作为客户端首先会请求DNS服务器，通过DNS服务器得到对应的IP地址和域名（应用层）
拿到解析后的IP地址建立TCP连接（传输层）
基于TCP连接，浏览器向服务器发送HTTP请求报文（应用层、传输层、网络层、数据链路层）
服务端收到HTTP请求后，开始处理请求报文（数据链路层、网络层、传输层、应用层）
在服务器收到请求后，服务器返回响应消息包
浏览器接收响应消息包后进行浏览器的布局渲染
释放TCP连接

七层、TCP/IP五层、四层

七层：应用层、表示层、会话层、传输层、网络层、数据链路层、网络层
TCP/IP五层：应用层、传输层、网络层、数据链路层、网络层
四层：应用层、传输层、网际互联层、网络接口层

TCP三次握手

第一次握手，处于close状态的客户端主动发起连接请求，发送SYN报文后客户端处于SYN_SENT状态；该报文不包含应用层数据；
第二次握手，一段时间后，处于listen状态的服务端收到SYN报文后，回复SYN+ACK 报文表示服务端收到了客户端发送过来的SYN报文；该报文不包含应用层数据；之后服务端处于SYN_RECV状态；
第三次握手，客户端接收到服务器发送的SYN+ACK报文后，再次向服务端发送ACK报文，之后处于established状态，TCP连接建立成功；一段时间后服务端收到该ACK报文后从SYN_RECV状态改为establisthed状态；此处过程是可以携带应用层数据的

TCP四次挥手

第一次挥手：处于established状态的客户端主动发起释放连接请求，客户端发生FIN报文，之后客户端处于FIN_Wait1状态；
第二次挥手：服务端收到客户端发送的FIN报文后，发送ACK报文，表明服务端已经收到客户端需要释放连接的请求，从estblished状态转成close_wait状态；并等待一段时间处理还未处理的数据并发送给客户端；
第三次挥手：服务端处理完待发送数据后，发送FIN报文给客户端，从close_wait状态转成last_ack状态；客户端在一段时间后收到服务端发送ACK报文后，从fin_wait1状态转为fin_wait2状态；
第四次挥手：客户端收到服务端发送的FIN报文后，回复ACK报文段，之后从fin_wait2状态转为time_wait状态，该状态主要是为了防止接收到历史连接的数据导致异常错误以及保证服务端能正常释放连接操作

TCP和UDP的区别

是否面向连接、传输方式、可靠的、所需资源、传输效率、应用场景、首部地址

TCP是面向连接的，传输数据之前需要先建立连接，只能一对一进行通信；UDP是无连接的，无需建立连接就可以进行数据传输，一对多、多对多
TCP是基于字节流的，流式传输，没有边界，但可以保证数据的有序性和可靠性；UDP是基于数据报文段的，保留数据边界
TCP有握手和挥手过程，所需资源多，传输效率慢；UDP所需资源少，传输效率高
TCP是可靠性交付数据的，数据可以无差错、不丢失、不重复、按需到达；UDP是尽最大努力交付，不保证数据的可靠性
TCP首部长度为20字节~60字节；UDP首部字节长度为8个字节
TCP常用于需要保证数据可靠性的场景，如FTP文件传输、HTTP/HTTPS；UDP常用于DNS、SNMP、视频音频、广播

HTTPS和HTTP的区别

关键词：加密、端口、CA、响应速度

HTTP是超文本传输协议，数据是采用明文传输，存在着安全风险。HTTPS则解决了HTTP不安全的问题，在TCP和HTTP网络层之间加入了SSL/TLS安全协议，使得报文能够加密传输
HTTP采用的80端口，HTTPS采用的是443端口
HTTPS协议需要想CA证书权威机构申请数字证书，来保证服务器身份是可信的
HTTP通过TCP三次挥手建立连接后就看进行数据传输，但HTTPS建立了TCP连接后还需要进行SSL/TLS的握手过程，才可以进行加密传输。

close_wait状态和time_wait状态的意义

close_wait状态意义：

close_wait状态处在开始于第二次挥手时，由服务端回复ACK报文给客户端，告知客户端已经收到了FIN报文，并准备释放连接操作；但此时，由于存在着一种情况，就是服务端还存在着一些未处理好数据并且需要发送给客户端，如果将close_wait状态取消并直接释放连接的话，就会导致上述结果的发生，因此不能立即释放连接，主要是为了保证服务器在关闭连接之前将之前待发送的数据传输完

time_wait状态的意义：

防止历史连接的数据导致不可预知的错误；保证被动关闭的一方能正常关闭

防止接收到历史连接的数据
该状态开始于第四次挥手，由客户端发送ACK报文后由FIN_wait状态改为time_wait状态；如果取消该状态，即客户端立即释放连接，那么假设该端口没有被释放的情况下，基于该端口重新建立了新连接，继续沿用旧的四元组，如果接收到了历史连接的延迟数据，延迟数据会导致新连接的数据之间出现数据错乱的异常结果发生
保证被动关闭的一方能正常关闭
假设第四次挥手时客户端发送的ACK报文丢失，服务端由于一段时间内没有收到ACK报文，就会触发服务端的超时重传机制，重发FIN报文；假设没有该状态，客户端就会立即释放连接，当客户端收到服务端重发的FIN报文后，会回复RST报文，使得服务端认为是有错误发生，然而实际上这是一个正常的释放连接的过程

TCP的keep_alive和HTTP的keep_alive有什么不同

http 应用层用户态建立tcp 请求资源响应资源释放连接短连接请求包头的connection字段 1.1默认开启减少开销，HTTP流水线技术提供保障服务器按照顺序响应 http长连接的超时时间 keepalive_timeout参数，定时器触发回调函数释放连接
tcp 传输层内核态 TCP保活机制、
TCP的keep_alive：

TCP的keep_alive也称为TCP的保活机制，该功能是由内核实现的。假设已经建立一个TCP连接，但可能会出现一段时间内没有数据的传输，但此时该连接仍然维持着，占有着系统资源。为了有效查析该连接是是否有效还是确实没有数据的传输，内核为了确保该连接是否还有效，就会发送一个TCP探测报文，来确定对方是否存活；如果在保活定时器时间结束之前收到了回复报文，就会知道对端是存活的，那么就会重新将保活定时器计时；如果连续几次没有响应，达到保活探测次数后，TCP会报告该TCP连接已经死亡；保活机制的设置是通过socket接口设置so_keepalive选项。
HTTP的keep_alive机制：
HTTP的keep_alive是处于应用层下的，由用户态所维护。HTTP采用的请求-应答模式，进行数据通信前需要先建立TCP连接，建立成功后通过请求资源、响应资源和释放连接结束这一过程；HTTP1.1之前的版本就是基于HTTP短连接的方式，每次请求都需要基于上述过程，存在着明显的创建、释放连接的资源开销问题。为了让多个HTTP请求能复用同一个TCP连接，HTTP1.1后默认开启长连接的方式，也就是使用用一个TCP连接来发送和接收多个HTTP请求应答，避免了创建连接和释放连接的开销，并且为HTTP流水线机制提供了保障，客户端一次性发送多条HTTP请求，但服务器按照顺序响应，此过程存在队头阻塞的问题，所以HTTP长连接可以进行对keepalive_timeout参数进行超时时间的设置。当定时器时间内没有新的请求，就会触发回调函数来释放该连接。