java八股复习指南-计网篇
网络分层模型
osi七层模型
tcp-ip四层模型
- 应用层
- 传输层
- 网络层
- 网络接口层
与osi七层模型对应为：
应用层
主要提供两个终端设备上应用之间的消息交换的服务。它定义了消息交换的格式。
常见协议有：
结合常见的协议，可以这样理解应用层：
应用层就是专门为特定的应用之间的通信提供服务
比如：http就是为web浏览器与web服务器提供服务，smtp就是为电子邮件从发送端到接收端提供服务。
传输层
负责向两台终端设备进程之间的通信提供通用的数据传输服务。
"通用的"即不指定特定的应用，正因如此，传输层作为应用层的下层，多种应用使用传输层向另一终端的应用进行通信。
常见协议
TCP（Transmission Control Protocol，传输控制协议 ）：提供 面向连接 的，可靠 的数据传输服务。
UDP（User Datagram Protocol，用户数据协议）：提供 无连接 的，尽最大努力 的数据传输服务（不保证数据传输的可靠性），简单高效。
网络层
负责为分组交换网上的不同主机提供通信服务
网络层的还有一个任务就是选择合适的路由，使源主机运输层所传下来的分组，能通过网络层中的路由器找到目的主机。
常见协议
网络接口层
我们可以把网络接口层看作是数据链路层和物理层的合体。
- 数据链路层(data link layer)通常简称为链路层（ 两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层交下来的 IP 数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
- 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异
常见协议
网络分层的原因
- 各层之间相互独立：各层之间不需要关心其他层如何实现，只需要知道如何调用其他层的接口即可。
- 提供整体灵活性：高内聚、低耦合 。每一层都可以使用最适合的技术来实现，你只需要保证你提供的功能以及暴露的接口的规则没有改变就行
- 大问题化小：将复杂问题拆分成简单问题，进而处理和解决。
WebSocket
WebSocket 是一种基于 TCP 连接的全双工通信协议，即客户端和服务器可以同时发送和接收数据。
客户端和服务器仅需一次握手，两者之间就直接可以创建持久性的连接，并进行双向数据传输。
WebSocket与Http的区别
WebSocket 和 HTTP 两者都是基于 TCP 的应用层协议，都可以在网络中传输数据。
区别
- WebSocket是一种双向的实时通信协议，而HTTP是单向的通信协议。HTTP只能由客户端向服务端发出请求
- WebSocket前缀是ws://或wss://，而HTTP前缀是http://或https://
- WebSocket 通信数据格式比较轻量，用于协议控制的数据包头部相对较小，网络开销小，而 HTTP 通信每次都要携带完整的头部，网络开销较大
TCP和UDP
TCP、UDP的区别
- 是否面向连接：UDP传输数据之前不需要建立连接，而TCP需要先建立连接，才开始传输数据，因此TCP是提供面向连接的服务。
- 是否可靠传输：UDP是不可靠的，TCP是可靠的
- 是否有状态：UDP是无状态的服务，简单说就是不管发出去之后的事情，不论是否收到或者是否有丢失。而TCP是有状态的服务，TCP会记录发出去的消息状态，如是否发送、是否接收等，因此TCP需要维持复杂的连接状态
- 传输效率：UDP不需要考虑连接等，而TCP需要考虑连接、确认、重传等机制，因此UDP效率比TCP高
- 传输形式：UDP是面向报文的，而TCP是面向字节流的
- 首部开销：UDP首部8字节，TCP首部20-60字节
- 是否提供广播或者多播服务：TCP仅支持1对1传输，而UDP支持1对1、1对多、多对1、多对多等
| TCP | UDP | |
|---|---|---|
| 是否面向连接 | 是 | 否 |
| 是否可靠 | 是 | 否 |
| 是否有状态 | 是 | 否 |
| 传输效率 | 较慢 | 较快 |
| 传输形式 | 字节流 | 数据报文段 |
| 首部开销 | 20 ～ 60 bytes | 8 bytes |
| 是否提供广播或多播服务 | 否 | 是 |
如何选择TCP与UDP
关键在数据传输的准确性
UDP：一般用于实时通信：比如语音、视频、直播
TCP：用于对准确性要求高的场景：比如文件传输、发送和接收文件
TCP三次握手与四次挥手
三次握手
建立一个 TCP 连接需要“三次握手”，缺一不可：
三次握手最主要的目的就是双方确认自己与对方的发送与接收是正常的。
- 一次握手:客户端发送带有 SYN（SEQ=x） 标志的数据包 -> 服务端，然后客户端进入 SYN_SEND 状态，等待服务端的确认；
一次握手，客户端什么都没确认，服务端确认了客户端的发送以及服务端的接收功能
- 二次握手:服务端发送带有 SYN+ACK(SEQ=y,ACK=x+1) 标志的数据包 –> 客户端,然后服务端进入 SYN_RECV 状态；
二次握手，客户端确认了自己的发送和接收功能、服务端的发送和接收功能；而服务端还是只确认了客户端的发送以及服务端的接收功能
- 三次握手:客户端发送带有 ACK(ACK=y+1) 标志的数据包 –> 服务端，然后客户端和服务端都进入ESTABLISHED 状态，完成 TCP 三次握手。
三次握手，客户端确认了自己的发送和接收功能、服务端的发送和接收功能；同时服务端确认了客户端的发送和接收功能以及服务端的发送和接收功能
四次挥手
断开一个 TCP 连接则需要“四次挥手”，缺一不可：
- 第一次挥手：客户端发送一个 FIN（SEQ=x） 标志的数据包->服务端，用来关闭客户端到服务端的数据传送。然后客户端进入 FIN-WAIT-1 状态。
- 第二次挥手：服务端收到这个 FIN（SEQ=X） 标志的数据包，它发送一个 ACK （ACK=x+1）标志的数据包->客户端 。然后服务端进入 CLOSE-WAIT 状态，客户端进入 FIN-WAIT-2 状态。
- 第三次挥手：服务端发送一个 FIN (SEQ=y)标志的数据包->客户端，请求关闭连接，然后服务端进入 LAST-ACK 状态。
- 第四次挥手：客户端发送 ACK (ACK=y+1)标志的数据包->服务端，然后客户端进入TIME-WAIT状态，服务端在收到 ACK (ACK=y+1)标志的数据包后进入 CLOSE 状态。此时如果客户端等待 2MSL 后依然没有收到回复，就证明服务端已正常关闭，随后客户端也可以关闭连接了。
只要四次挥手没有结束，客户端和服务端就可以继续传输数据！
为什么是四次挥手，比三次握手还要多一次？
TCP属于双向通信，当客户端发起断开请求时，在经过第一次、第二次挥手后，只是确认了服务端收到客户端的请求，但可能服务端还有数据没有发送完毕。因此，直到服务端发送完所有数据后，才会发起第三次挥手，而在客户端发出第四次挥手后，证明双方都收到了断开的请求，然后才真正断开连接。
也就是说第二三次之间，可能仍然有数据的传输。因此第二三次并不能合并
通过JavaGuide学习提炼，详情可访问 https://javaguide.cn/
