八股文|计算机网络_八股文计算机

OSI七层模型

OSI七层协议包括：物理层，数据链路层，网络层，运输层，会话层，表示层， 应用层
每一层都专注做一件事情，并且每一层都需要使用下一层提供的功能比如传输层需要使用网络层提供的路由和寻址功能，这样传输层才知道把数据传输到哪里去。
OSI 的七层体系结构概念清楚，理论也很完整，但是它比较复杂而且不实用，而且有些功能在多个层中重复出现。
有了OSI七层模型，为什么还要TCP/IP四层模型？

1. OSI 的专家缺乏实际经验，他们在完成 OSI 标准时缺乏商业驱动力
2. OSI 的协议实现起来过分复杂，而且运行效率很低
3. OSI 制定标准的周期太长，因而使得按 OSI 标准生产的设备无法及时进入市场（20 世纪 90 年代初期，虽然整套的 OSI 国际标准都已经制定出来，但基于 TCP/IP 的互联网已经抢先在全球相当大的范围成功运行了）
4. OSI 的层次划分不太合理，有些功能在多个层次中重复出现。

TCP四层模型

目前被广泛采纳的一种模型，可以将TCP/IP模型看作是OSI模型的精简版，由以下四层组成：
1．网络接口层 2. 网络层 3. 传输层 4. 应用层
我们并不能将 TCP/IP 四层模型 和 OSI 七层模型完全精确地匹配起来，不过可以简单将两者对应起来

应用层(Application Layer)

应用层位于传输层之上，主要提供两个终端设备上的应用程序之间信息交换的服务，它定义了信息交换的格式，消息会交给下一层传输层来传输。应用层相互交互的数据单元称为报文。
应用层协议定义了网络通信规则，对于不同的网络应用需要不同的应用层协议。在互联网中应用层协议很多，如支持 Web 应用的 HTTP 协议，支持电子邮件的 SMTP 协议等等。

传输层(Transport Layer)

传输层的主要任务就是负责向两台终端设备进程之间的通信提供通用的数据传输服务。应用进程利用该服务传送应用层报文。“通用的”是指并不针对某一个特定的网络应用，而是多种应用可以使用同一个运输层服务。
传输层主要有两种协议：

• 传输控制协议TCP(Transmission Control Protocol)—提供面向连接的，可靠的数据传输服务。
• 用户数据协议UDP(User Datagram Protocol)—提供无连接的，不可靠的数据传输服务(尽最大努力传输)。

网络层(Network Layer)

网络层负责为分组交换网上的不同主机提供通信服务。在发送数据时，网络层把传输层产生的报文段或用户数据报封装成分组和包进行传送。在 TCP/IP 体系结构中，由于网络层使用 IP 协议，因此分组也叫 IP 数据报，简称数据报。网络层的还有一个任务就是选择合适的路由，使源主机传输层所传下来的分组，能通过网络层中的路由器找到目的主机。

网络接口层(Network Interface Layer)

网络接口层是数据链路层和物理层的结合

• 数据链路层(data link layer)通常简称为链路层（两台主机之间的数据传输，总是在一段一段的链路上传送的）。数据链路层的作用是将网络层交下来的 IP数据报组装成帧，在两个相邻节点间的链路上传送帧。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。
• 物理层的作用是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异

HTTP协议

HTTP 协议，全称超文本传输协议（Hypertext Transfer Protocol）。顾名思义，HTTP 协议就是用来规范超文本的传输，超文本，也就是网络上的包括文本在内的各式各样的消息，具体来说，主要是来规范浏览器和服务器端的行为的。是一个无状态(stateless)的协议，不维护任何有关客户端过去所发请求的消息，因为维护历史状态，解决状态不一致需要的代价更高。

HTTP协议通信过程

HTTP 是应用层协议，它以 TCP（传输层）作为底层协议，默认端口为 80. 通信过程主要如下：

1. 服务器在 80 端口等待客户的请求。
2. 浏览器发起到服务器的 TCP 连接（创建套接字 Socket）。
3. 服务器接收来自浏览器的 TCP 连接。
4. 浏览器（HTTP 客户端）与 Web 服务器（HTTP 服务器）交换 HTTP 消息。
5. 关闭 TCP 连接。

HTTPS协议

• HTTPS 协议（Hyper Text Transfer Protocol Secure），是 HTTP 的加强安全版本。HTTPS 是基于 HTTP 的，也是用 TCP 作为底层协议，并额外使用 SSL/TLS 协议用作加密和安全认证。默认端口号是 443。HTTPS 协议中，SSL 通道通常使用基于密钥的加密算法，密钥长度通常是 40 比特或 128 比特。
• HTTPS 的核心—SSL/TLS协议：HTTPS 之所以能达到较高的安全性要求，就是结合了 SSL/TLS 和 TCP 协议，对通信数据进行加密，解决了 HTTP 数据透明的问题。接下来重点介绍一下 SSL/TLS 的工作原理。

SSL和TLS的区别

SSL 指安全套接字协议（Secure Sockets Layer），首次发布与 1996 年。SSL 的首次发布其实已经是他的 3.0 版本，SSL 1.0 从未面世，SSL 2.0 则具有较大的缺陷（DROWN 缺陷——Decrypting RSA with Obsolete and Weakened eNcryption）。很快，在 1999 年，SSL 3.0 进一步升级，新版本被命名为 TLS 1.0。因此，TLS 是基于 SSL 之上的，但由于习惯叫法，通常把 HTTPS 中的核心加密协议混成为 SSL/TLS。

SSL/TLS工作原理

• SSL/TLS对传输内容使用对称加密进行加密，但对对称加密的密钥用服务器方的证书进行了非对称加密。
• SSL/TLS的核心要素是非对称加密。但非对称加密设计了较为复杂的数学算法，在实际通信过程中，计算的代价较高，效率太低，因此，SSL/TLS 实际对消息的加密使用的是对称加密，在双方通信之前要商量一个用于对称加密的密钥。网络信道是不安全的，密钥的交换不能直接在网络信道中传输，因此要使用非对称加密对对称加密的密钥进行加密，保护密钥不在网络信道中被窃听。通信双方只需要一次非对称加密交换对称加密的密钥，在今后的通信中，使用绝对安全的密钥，对信息进行对称加密，即可保证消息传输的保密性。
• 服务端的公钥在网络中传输时，可能会被欺诈服务器发送另外一个公钥给目的客户端，导致客户端使用欺诈服务器的公钥进行加密数据，所以需要使用CA颁发的数字证书。
• 数字签名技术是为了防止数字证书被伪造的技术，CA先对服务器的公钥进行散列获取一个摘要，然后用CA自己的私钥对服务器的公钥进行加密附在数字证书中发给服务器。服务器发送证书给客户端时，客户端找到第三方机构CA，用CA的公钥对证书的签名进行解密获得了CA生成的摘要。同时，客户端对服务器的公钥做相同的散列出来，对比得到的摘要是否相同即可确认服务器的身份。

HTTP1.0VSHTTP1.1(应用层)

响应状态码：HTTP/1.0仅定义了16种状态码。HTTP/1.1中新加入了大量的状态码，光是错误响应状态码就新增了24种。比如说，100 (Continue)——在请求大资源前的预热请求，206 (Partial Content)——范围请求的标识码，409 (Conflict)——请求与当前资源的规定冲突，410 (Gone)——资源已被永久转移，而且没有任何已知的转发地址。
缓存处理：在 HTTP1.0 中主要使用 header 里的 If-Modified-Since,Expires 来做为缓存判断的标准，HTTP1.1 则引入了更多的缓存控制策略例如 Entity tag，If-Unmodified-Since, If-Match, If-None-Match 等更多可供选择的缓存头来控制缓存策略。
连接方式：

• HTTP 1.0 为短连接，客户端和服务器每进行一次 HTTP 操作，就建立一次连接，任务结束就中断连接，导致有大量的“握手报文”和“挥手报文”占用了带宽。
• HTTP 1.1 支持长连接，在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输 HTTP 数据的 TCP 连接不会关闭，客户端再次访问这个服务器时，会继续使用这一条已经建立的连接。
  Host头处理：域名系统（DNS）允许多个主机名绑定到同一个IP地址上，但是HTTP/1.0并没有考虑这个问题，假设我们有一个资源URL是http://example1.org/home.html，HTTP/1.0的请求报文中，将会请求的是GET /home.html HTTP/1.0.也就是不会加入主机名。这样的报文送到服务器端，服务器是理解不了客户端想请求的真正网址(该ip下的哪一个主机上的资源)。因此，HTTP/1.1在请求头中加入了Host字段。加入Host字段的报文头部将会是：GET /home.html HTTP/1.1 Host: example1.org
  带宽优化：
• HTTP/1.1引入了范围请求（range request）机制，以避免带宽的浪费
• HTTP/1.1中新加入了状态码100，该状态码的使用场景为，存在某些较大的文件请求，服务器可能不愿意响应这种请求，此时状态码100可以询问客户端是否确实需要这个资源。
• 数据的压缩可以大幅优化带宽的利用，然而，HTTP/1.0对数据压缩的选项提供的不多，不支持压缩细节的选择，也无法区分端到端（end-to-end）压缩或者是逐跳（hop-by-hop）压缩。HTTP/1.1加入了Transfer-Encoding头部，可以对消息进行逐跳传输编码。HTTP/1.1还加入了Accept-Encoding头部，是客户端用来指示他能处理什么样的内容编码。

应用层常见协议

HTTP：超文本传输协议

超文本传输协议（HTTP，HyperText Transfer Protocol) 主要是为 Web 浏览器与 Web 服务器之间的通信而设计的。当我们使用浏览器浏览网页的时候，我们网页就是通过 HTTP 请求进行加载的，整个过程如下图所示

HTTP 协是基于 TCP协议，发送 HTTP 请求之前首先要建立 TCP 连接也就是要经历 3 次握手。目前使用的 HTTP 协议大部分都是 1.1。在 1.1 的协议里面，默认是开启了 Keep-Alive 的，这样的话建立的连接就可以在多次请求中被复用了。另外， HTTP 协议是”无状态”的协议，它无法记录客户端用户的状态，一般我们都是通过 Session 来记录客户端用户的状态。

SMTP:简单邮件传输协议

简单邮件传输(发送)协议（SMTP，Simple Mail Transfer Protocol） 基于 TCP 协议，用来发送电子邮件的协议。注意：接受邮件的协议不是 SMTP 而是 POP3 协议。
电子邮件的发送过程：
比如我的邮箱是“dabai@cszhinan.com”，我要向“xiaoma@qq.com”发送邮件，整个过程可以简单分为下面几步：

1. 通过 SMTP 协议，我将我写好的邮件交给163邮箱服务器（邮局）。
2. 163邮箱服务器发现我发送的邮箱是qq邮箱，然后它使用 SMTP协议将我的邮件转发到 qq邮箱服务器。
3. qq邮箱服务器接收邮件之后就通知邮箱为“xiaoma@qq.com”的用户来收邮件，然后用户就通过 POP3/IMAP 协议将邮件取出。
   如何判断邮箱是真正存在的：
4. 查找邮箱域名对应的 SMTP 服务器地址
5. 尝试与服务器建立连接
6. 连接成功后尝试向需要验证的邮箱发送邮件
7. 根据返回结果判定邮箱地址的真实性

POP3/IMAP:邮件接收的协议

POP3 和 IMAP 两者都是负责邮件接收的协议，IMAP 协议相比于POP3更新一点，为用户提供的可选功能也更多一点,几乎所有现代电子邮件客户端和服务器都支持IMAP。
FTP:文件传输协议
FTP 协议 主要提供文件传输服务，基于 TCP 实现可靠的传输。FTP 是基于客户—服务器（C/S）模型而设计的，FTP 的独特的优势同时也是与其它客户服务器程序最大的不同点就在于它在两台通信的主机之间使用了两条 TCP 连接（其它客户服务器应用程序一般只有一条 TCP 连接），这种将命令和数据分开传送的思想大大提高了 FTP 的效率：

• 控制连接：用于传送控制信息（命令和响应）
• 数据连接：用于数据传送；

Telnet:远程登陆协议

Telnet 协议 通过一个终端登陆到其他服务器，建立在可靠的传输协议 TCP 之上。Telnet 协议的最大缺点之一是所有数据（包括用户名和密码）均以明文形式发送，这有潜在的安全风险。这就是为什么如今很少使用Telnet并被一种称为SSH的非常安全的协议所取代的主要原因。
SSH:安全的网络传输协议
SSH（ Secure Shell） 是目前较可靠，专为远程登录会话和其他网络服务提供安全性的协议。利用 SSH 协议可以有效防止远程管理过程中的信息泄露问题。SSH 建立在可靠的传输协议 TCP 之上。Telnet 和 SSH 之间的主要区别在于 SSH 协议会对传输的数据进行加密保证数据安全性。

TCP协议相关

TCP 三次握手

为了准确无误地把数据送达目标处，TCP 协议采用了三次握手策略。

• 客户端——发送带有 SYN 标志的数据包——一次握手——服务端
• 服务端——发送带有 SYN/ACK 标志的数据包——二次握手——客户端
• 客户端——发送带有带有 ACK 标志的数据包——三次握手——服务端

为什么要进行三次握手

三次握手的目的是建立可靠的通信通道，三次握手双方才能确定自己与对方的发送和接收都是正常的。
第一次握手：Client什么都不能确认，Server确认了Client端能正常发送，自己能正常接收
第二次握手：Client确认自己能正常发送，正常接收，Server正常发送，正常接收
第三次握手：Server端确认了自己能正常发送，Client端能正常接收。
第二次握手传回了ACK，为什么还要传回SYN
服务端传给客户端的 ACK 是为了告诉客户端，我接收到的信息确实就是你所发送的，这表明从客户端到服务端的通信是正常的。而回传 SYN 则是为了建立并确认从服务端到客户端的通信。

TCP四次挥手

• 客户端-发送一个 FIN，用来关闭客户端到服务器的数据传送
• 服务器-收到这个 FIN，它发回一 个 ACK，确认序号为收到的序号加 1 。和 SYN 一样，一个 FIN 将占用一个序号
• 服务器-关闭与客户端的连接，发送一个 FIN 给客户端
• 客户端-发回 ACK 报文确认，并将确认序号设置为收到序号加 1
  为什么要四次挥手
• 任何一方都可以在数据传送结束后发出连接释放的通知，待对方确认后进入半关闭状态。当另一方也没有数据再发送的时候，则发出连接释放通知，对方确认后就完全关闭了 TCP 连接。（举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B 回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。）

TCP,UDP协议的区别

• UDP 在传送数据之前不需要先建立连接，远地主机在收到 UDP 报文后，不需要给出任何确认。虽然 UDP 不提供可靠交付，但在某些情况下 UDP 却是一种最有效的工作方式，一般用于即时通信，比如： QQ 语音、 QQ 视频 、直播等等
• TCP 提供面向连接的服务。在传送数据之前必须先建立连接，数据传送结束后要释放连接。 TCP 不提供广播或多播服务。由于 TCP 要提供可靠的，面向连接的传输服务，这难以避免增加了许多开销。这不仅使协议数据单元的首部增大很多，还要占用许多处理机资源。TCP 一般用于文件传输、发送和接收邮件、远程登录等场景。

TCP 协议如何保证可靠传输

• 应用数据被分割成 TCP 认为最适合发送的数据块。
• TCP 给发送的每一个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。
• 校验和： TCP 将保持它首部和数据的检验和。这是一个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。
• TCP 的接收端会丢弃重复的数据。
• 流量控制： TCP 连接的每一方都有固定大小的缓冲空间，TCP 的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。 （TCP 利用滑动窗口实现流量控制）
• 拥塞控制： 当网络拥塞时，减少数据的发送。
• ARQ 协议： 也是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。
• 超时重传： 当 TCP 发出一个段后，它启动一个定时器，等待目的端确认收到这个报文段。如果不能及时收到一个确认，将重发这个报文段。

ARQ 协议

自动重传请求（Automatic Repeat-reQuest，ARQ）是 OSI 模型中数据链路层和传输层的错误纠正协议之一。它通过使用确认和超时这两个机制，在不可靠服务的基础上实现可靠的信息传输。如果发送方在发送后一段时间之内没有收到确认帧，它通常会重新发送。ARQ 包括停止等待 ARQ 协议和连续 ARQ 协议。

停止等待 ARQ 协议

停止等待协议是为了实现可靠传输的，它的基本原理就是每发完一个分组就停止发送，等待对方确认（回复 ACK）。如果过了一段时间（超时时间后），还是没有收到 ACK 确认，说明没有发送成功，需要重新发送，直到收到确认后再发下一个分组。在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认。

连续 ARQ 协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累积确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。

滑动窗口和流量控制

TCP 利用滑动窗口实现流量控制。流量控制是为了控制发送方发送速率，保证接收方来得及接收。 接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而影响发送方的发送速率。将窗口字段设置为 0，则发送方不能发送数据。