文章目录
本文主要源自 JavaGuide 地址：https://github.com/Snailclimb/JavaGuide 作者：SnailClimb
仅供个人复习使用
3.1 TCP 和 UDP 协议的区别
-
UDP 在传送数据之前不需要先建立连接，目标主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式（一般用于即时通信），比如： QQ 语音、 QQ 视频 、直播等等。
-
TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的运输服务（TCP的可靠体现在TCP在传递数据之前，会有三次握手来建立连接，而且在数据传递时，有确认、窗口、重传、拥塞控制机制，在数据传完后，还会断开连接用来节约系统资源），这一难以避免增加了许多开销，如确认，流量控制，计时器以及连接管理等。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。
3.2 在浏览器中输入url地址 ->> 显示主页的过程
总的来说分为以下几个过程：
- DNS 解析
- TCP 连接
- 发送 HTTP 请求
- 服务器处理请求并返回 HTTP 报文
- 浏览器解析渲染页面
- 连接结束
具体过程参考：前端经典面试题: 从输入URL到页面加载发生了什么？
3.3 各种协议与HTTP协议之间的关系
3.4 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协议的长连接和短连接，实质上是TCP协议的长连接和短连接。
3.5 TCP 三次握手和四次挥手(面试常客)
1. 三次握手
三次握手过程
为什么需要三次握手，两次不行吗？
弄清这个问题，我们需要先弄明白三次握手的目的是什么，能不能只用两次握手来达到同样的目的。
- 第一次握手：客户端发送网络包，服务端收到了。
这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。 - 第二次握手：服务端发包，客户端收到了。
这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。 - 第三次握手：客户端发包，服务端收到了。
这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
因此，需要三次握手才能确认双方的接收与发送能力是否正常。
如果是用两次握手，则会出现下面这种情况：
客户端发出第一个请求连接报文①但延时了，所以就重新发起第二次连接②。服务端收到②后，返回确认报文③，这时双方建立连接，并在传输完数据后释放连接。
但当延时后的报文①到达之后，服务端以为又是一次新的连接，于是返回确认报文④，并且由于是两次握手，只要服务端发出确认，就建立新的连接了，所以此时服务端处于 established 状态。但实际上客户端并没有发起连接，因此会忽略报文④。因此，这就导致了服务端一直是等待数据的状态，浪费资源。
2. 四次挥手
四次挥手过程
挥手为什么需要四次？
建立连接时，当服务端收到客户端的 SYN 连接请求报文后，可以直接发送 SYN+ACK 报文。其中 ACK 报文是用来应答的， SYN 报文是用来同步的。
但是关闭连接时，当服务端收到 FIN 报文时，很可能并不会立即关闭 SOCKET ，所以只能先回复一个 ACK 报文，告诉客户端：“你发的 FIN 报文我收到了”，意味着前两次挥手只是关闭了 客户端 -> 服务端 的单向连接。只有等到我服务端所有的报文都发送完了，我才能发送 FIN 报文，意味着关闭 服务端 -> 客户端 的单向连接。因此不能一起发送。故需要四次挥手。
四次挥手释放连接时，等待2MSL的意义?
MSL是Maximum Segment Lifetime的英文缩写，可译为“最长报文段寿命”，它是任何报文在网络上存在的最长时间，超过这个时间报文将被丢弃。
-
保证客户端发送的最后一个ACK报文段能够到达服务端。
这个 ACK 报文段有可能丢失，使得处于 LAST-ACK 状态的 B 收不到对已发送的 FIN+ACK 报文段的确认，服务端超时重传 FIN+ACK 报文段，而客户端能在 2MSL 时间内收到这个重传的 FIN+ACK 报文段，接着客户端重传一次确认，重新启动 2MSL 计时器，最后客户端和服务端都进入到 CLOSED 状态。
若客户端在 TIME-WAIT 状态不等待一段时间，而是发送完 ACK 报文段后立即释放连接，则无法收到服务端重传的 FIN+ACK 报文段，所以不会再发送一次确认报文段，则服务端无法正常进入到 CLOSED 状态。 -
防止“已失效的连接请求报文段”出现在本连接中。
客户端在发送完最后一个 ACK 报文段后，再经过 2MSL ，就可以使本连接持续的时间内所产生的所有报文段都从网络中消失，使下一个新的连接中不会出现这种旧的连接请求报文段。
tips：三次握手和四次握手参考博客：面试官，不要再问我三次握手和四次挥手