1.各层作用及协议
| 分层 |
作用 |
协议 |
| 物理层 |
通过媒介传输比特，确定机械及电气规范（比特Bit） |
RJ45、CLOCK、IEEE802.3（中继器，集线器） |
| 数据链路层 |
将比特组装成帧和点到点的传递（帧Frame） |
PPP、FR、HDLC、VLAN、MAC（网桥，交换机） |
| 网络层 |
负责数据包从源到宿的传递和网际互连（包Packet） |
IP、ICMP、ARP、RARP、OSPF、IPX、RIP、IGRP（路由器） |
| 运输层 |
提供端到端的可靠报文传递和错误恢复（段Segment） |
TCP、UDP、SPX |
| 会话层 |
建立、管理和终止会话（会话协议数据单元 SPDU） |
NFS、SQL、NETBIOS、RPC |
| 表示层 |
对数据进行翻译、加密和压缩（表示协议数据单元 PPDU） |
JPEG、MPEG、ASII |
| 应用层 |
允许访问OSI环境的手段（应用协议数据单元 APDU） |
FTP、DNS、Telnet、SMTP、HTTP、WWW、NFS |
2.TCP 与 UDP 的区别
- TCP 面向连接，UDP 是无连接的；
- TCP 提供可靠的服务，也就是说，通过 TCP 连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP 尽最大努力交付，即不保证可靠交付；
- TCP 的逻辑通信信道是全双工的可靠信道；UDP 则是不可靠信道；
- 每一条 TCP 连接只能是点到点的；UDP 支持一对一，一对多，多对一和多对多的交互通信；
- TCP 面向字节流（可能出现黏包问题），实际上是 TCP 把数据看成一连串无结构的字节流；UDP 是面向报文的（不会出现黏包问题）
- UDP 没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如 IP 电话，实时视频会议等）
- TCP 首部开销20字节；UDP 的首部开销小，只有 8 个字节。
3.TCP 黏包问题
- 原因：TCP 是一个基于字节流的传输服务（UDP 基于报文的），“流” 意味着 TCP 所传输的数据是没有边界的。所以可能会出现两个数据包黏在一起的情况。
- 解决：
- 发送定长包。如果每个消息的大小都是一样的，那么在接收对等方只要累计接收数据，直到数据等于一个定长的数值就将它作为一个消息。
- 包头加上包体长度。包头是定长的 4 个字节，说明了包体的长度。接收对等方先接收包头长度，依据包头长度来接收包体。
- 在数据包之间设置边界，如添加特殊符号 \r\n 标记。FTP 协议正是这么做的。但问题在于如果数据正文中也含有 \r\n，则会误判为消息的边界。
- 使用更加复杂的应用层协议。
4.TCP 流量控制
- 概念：流量控制（flow control）就是让发送方的发送速率不要太快，要让接收方来得及接收。
- 方法：利用可变窗口进行流量控制。
5.TCP 拥塞控制
- 概念：拥塞控制就是防止过多的数据注入到网络中，这样可以使网络中的路由器或链路不致过载。
- 方法：
- 慢开始( slow-start )—拥塞避免( congestion avoidance )
- 快重传( fast retransmit )——快恢复( fast recovery )
6.TCP 三次握手建立连接【TCP 建立连接全过程解释】
- 客户端发送 SYN 给服务器，说明客户端请求建立连接；
- 服务端收到客户端发的 SYN，并回复 SYN+ACK 给客户端（同意建立连接）；
- 客户端收到服务端的SYN+ACK后，回复 ACK 给服务端（表示客户端收到了服务端发的同意报文）；
- 服务端收到客户端的 ACK，连接已建立，可以数据传输。
7.TCP 为什么要进行三次握手？
【答案一】因为信道不可靠，而 TCP 想在不可靠信道上建立可靠地传输，那么三次通信是理论上的最小值（而 UDP 则不需建立可靠传输，因此 UDP 不需要三次握手。）
【答案二】因为双方都需要确认对方收到了自己发送的序列号，确认过程最少要进行三次通信。
【答案三】为了防止已失效的连接请求报文段突然又传送到了服务端，因而产生错误。
8.TCP 四次挥手释放连接【TCP 释放连接全过程解释】
- 客户端发送FIN给服务器，说明客户端不必发送数据给服务器（请求释放从客户端到服务器的连接）；
- 服务器接收到客户端发的 FIN，并回复 ACK 给客户端（同意释放从客户端到服务器的连接）；
- 客户端收到服务端回复的 ACK，此时从客户端到服务器的连接已释放（但服务端到客户端的连接还未释放，并且客户端还可以接收数据）；
- 服务端继续发送之前没发完的数据给客户端；
- 服务端发送 FIN+ACK 给客户端，说明服务端发送完了数据（请求释放从服务端到客户端的连接，就算没收到客户端的回复，过段时间也会自动释放）；
- 客户端收到服务端的 FIN+ACK，并回复 ACK 给客户端（同意释放从服务端到客户端的连接）；
- 服务端收到客户端的 ACK 后，释放从服务端到客户端的连接。
9.TCP 为什么要进行四次挥手？
【问题一】TCP 为什么要进行四次挥手？ / 为什么 TCP 建立连接需要三次，而释放连接则需要四次？
【答案一】因为 TCP 是全双工模式，客户端请求关闭连接后，客户端向服务端的连接关闭（一二次挥手），服务端继续传输之前没传完的数据给客户端（数据传输），服务端向客户端的连接关闭（三四次挥手）。所以 TCP 释放连接时服务器的 ACK 和 FIN 是分开发送的（中间隔着数据传输），而 TCP 建立连接时服务器的 ACK 和 SYN 是一起发送的（第二次握手），所以 TCP 建立连接需要三次，而释放连接则需要四次。
【问题二】为什么 TCP 连接时可以 ACK 和 SYN 一起发送，而释放时则 ACK 和 FIN 分开发送呢？（ACK 和 FIN 分开是指第二次和第三次挥手）
【答案二】因为客户端请求释放时，服务器可能还有数据需要传输给客户端，因此服务端要先响应客户端 FIN 请求（服务端发送 ACK），然后数据传输，传输完成后，服务端再提出 FIN 请求（服务端发送 FIN）；而连接时则没有中间的数据传输，因此连接时可以 ACK 和 SYN 一起发送。
【问题三】为什么客户端释放最后需要 TIME-WAIT 等待 2MSL 呢？
【答案三】1.为了保证客户端发送的最后一个 ACK 报文能够到达服务端。若未成功到达，则服务端超时重传 FIN+ACK 报文段，客户端再重传 ACK，并重新计时。
2.防止已失效的连接请求报文段出现在本连接中。TIME-WAIT 持续 2MSL 可使本连接持续的时间内所产生的所有报文段都从网络中消失，这样可使下次连接中不会出现旧的连接报文段。
10.状态码（Status-Code）
（1）1xx：表示通知信息，如请求收到了或正在进行处理。
100 Continue：继续，客户端应继续其请求。
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到 HTTP 的新版本协议。
（2）2xx：表示成功，如接收或知道了。
200 OK: 请求成功。
（3）3xx：表示重定向，如要完成请求还必须采取进一步的行动。
301 Moved Permanently: 永久移动。请求的资源已被永久的移动到新 URL，返回信息会包括新的 URL，浏览器会自动定向到新 URL。今后任何新的请求都应使用新的 URL 代替。
（4）4xx：表示客户的差错，如请求中有错误的语法或不能完成。
400 Bad Request: 客户端请求的语法错误，服务器无法理解。
401 Unauthorized: 请求要求用户的身份认证。
403 Forbidden: 服务器理解请求客户端的请求，但是拒绝执行此请求（权限不够）
404 Not Found: 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置 “您所请求的资源无法找到” 的个性页面。
408 Request Timeout: 服务器等待客户端发送的请求时间过长，超时。
（5）5xx：表示服务器的差错，如服务器失效无法完成请求。
500 Internal Server Error: 服务器内部错误，无法完成请求。
503 Service Unavailable: 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的 Retry-After 头信息中。
504 Gateway Timeout: 充当网关或代理的服务器，未及时从远端服务器获取请求。
（欢迎您的意见和建议，感谢支持！！！❤❤❤）