2020秋招_TCP/IP协议知识（笔记）

网络OSI模型

开放式系统互联模型（Open System Interconnection Model，简称为OSI模型），一共有7层。
7.应用层、6.表达层、5.会话层、4.传输层、3.网络层、2.数据链路层、1.物理层

网络模型分几个层次

四个层次：应用层、传输层（TCP、UDP）、网络层（IP）、网络接口层（socket）。

TCP协议和IP协议的关系

网络模型中，TCP协议位于传输层，IP协议位于网络层，传输层位于网络层上一层。
TCP协议主要是提供处于网络连接中的两台计算机之间的可靠的数据传输方式；IP协议规定了通过怎样的路径（所谓的传输路线）到达对方计算机，并把数据包传送给对方，即路由方式。
发送端通过每一层增加首部，接收端通过每一层删除首部。
传输层（TCP协议）把从应用层处收到的数据（HTTP报文）进行分割，并在各个报文上打上标记序号及端口号后转发给网络层；在网络层（IP协议）增加作为通信目的地的MAC地址后转发给链路层。

TCP和UDP的区别

	TCP	UDP
可靠性	可靠	不可靠
连接性	面向连接	无连接
报文	面向字节流（无边界）	面向报文（保留报文边界）
效率	传输效率低	传输效率高
双工性	全双工（点到点）	一对一，一对多，多对多
流量控制	有	无
拥塞控制	有	无

TCP相比UDP为什么是可靠的？

TCP是面向连接的，并通过三次握手建立可靠的连接；UDP是无连接的。

• TCP 连接使用三次握手的首要原因 —— 为了阻止历史的重复连接初始化造成的混乱问题，防止使用 TCP 协议通信的双方建立了错误的连接；
• 通过三次握手才能对通信双方的初始序列号进行初始化；
• 讨论其他次数握手建立连接的可能性；

TCP三次握手过程，为什么是三次而不是两次或四次？

两张动图-彻底明白TCP的三次握手与四次挥手
TCP 为什么三次握手而不是两次握手（正解版）
四次握手过程：

1. 客户端向服务端发送SYN同步请求；
2. 服务端向客户端返回ACK确认同步；
3. 服务端向客户端发送SYN同步请求；
4. 客户端向服务端返回ACK确认同步。

显然，四次握手中的第二次和第三次握手都是服务端向客户端发送，因此可以简化成三次握手，提高建立连接的效率。

三握手过程：

1. 客户端向服务端发送SYN同步请求；
2. 服务端向客户端返回ACK确认同步，并发送SYN同步请求；
3. 客户端向服务端返回ACK确认同步。

为了实现可靠数据传输， TCP 协议的通信双方， 都必须维护一个序列号， 以标识发送出去的数据包中， 哪些是已经被对方收到的（发送请求报文一方如果没收到对方的ACK确认，会超时重传请求报文，一直到收到对方的ACK确认为止。这些重传的请求报文的序列号起始值都一样，如果有请求报文因为延时过了一段时间才到达的，也不会被重复接收）。
三次握手的过程即是通信双方相互告知序列号起始值， 并确认对方已经收到了序列号起始值的必经步骤。如果只是两次握手， 至多只有连接发起方的起始序列号能被确认， 另一方选择的序列号则得不到确认。

TCP如何保证可靠传输？(侧重于传输过程)

TCP/IP可靠传输的基础是滑动窗口协议和连续ARQ（自动重传请求）协议，配合着流量控制和拥塞控制，使得整个传输过程保证：

1. 传输信道不产生差错；
2. 不管发送方以多快的速度发送数据，接收方总是来得及处理收到的数据（通过累计确认、超时重传、流量控制、拥塞控制等保证）。

如何确认的？ -> 连续ARQ协议

发送端是如何确认需要重传哪些包的?

停止等待协议：发送方每发送完一个报文分组就停止发送（同时启动一个定时器），等待对方确认；接收方收到报文就会向发送方确认，发送方发送一段时间后没有收到确认消息就重传（超时重传）；发送方在收到确认后再发送下一个报文分组。
滑动窗口协议：发送方和接收方各自维持着发送窗口和接收窗口，发送方每收到一个确认，就把发送窗口向前滑动一个报文段的位置。接收方一般采用累计确认的方式。
连续ARQ协议：发送方维持一个窗口，凡是位于窗口内的报文段可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个报文段发送累计的确认，表明这个报文段为止的所有报文段都已经确认收到了。
（优点：信道利用率高，容易实现，即使接收方返回的确认丢失，也不必重传；缺点：窗口内中间某个报文段丢失，窗口内该丢失报文段之后的报文段都需要重新发送，因为中间报文段丢失了，之后的报文段便无法被确认）

流量控制和拥塞控制区别

流量控制：当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。
拥塞控制：当网络拥塞时，减少数据的发送。（维持一个拥塞窗口cwnd，cwnd = min(rwnd，cwnd)；拥塞控制算法：慢开始、拥塞避免、快重传和快恢复）
拥塞控制是一个全局性的过程，涉及到所有主机，所有网络，以及与降低网络性能有关的所有因素。相反，流量控制往往是点到点通信量的控制，是个端到端的过程。流量控制所要做的是抑制发送端发送数据的速率，以便接收端来得及接收。

time_wait状态

time_wait持续时间为两个最长报文段寿命。
当客户端或者服务端先关闭（Ctrl+C）的一方会进入time_wait状态。
作用：

1. 保证客户端发送的最后一个ACK报文能到达服务器；
2. 使本次连接持续的时间内所产生的所有报文段都从网络中消失，这样新的连接中不会出现旧连接的请求报文。

TCP粘包TCP和HTTP的关系，HTTP还可以基于什么传输

主要原因是TCP以字节流形式传输，无报文边界。（粘包问题是可以通过程序解决的，例如读取HTTP报文的时候一般以/r/n作为报文每一行换行标志，空行/r/n用来区分报文首部和报文主体，报文主体的长度可以根据首部字段Content-Length获得，这样便可以读取一个完整的HTTP报文）

TCP粘包，拆包及解决方法、丢包的原因及解决办法

TCP粘包，拆包及解决方法、丢包的原因及解决办法

从输入URL到页面加载发生了什么？

前端经典面试题: 从输入URL到页面加载发生了什么？
总体来说分为以下几个过程:

1. DNS解析：寻找哪台机器上有你需要资源的过程。
2. TCP连接：HTTP协议是使用TCP作为其传输层协议的，当TCP出现瓶颈时，HTTP也会受到影响。
3. 发送HTTP请求
4. 服务器处理请求并返回HTTP报文
5. 浏览器解析渲染页面
6. 连接结束

TCP和HTTP的关系，HTTP还可以基于什么传输？

TCP和Http的区别!我都搞懂了,你就别迷糊了!
TCP位于网络模型的传输层，是传输层协议，定义的是数据传输和连接方式的规范；HTTP位于网络模型的应用层，是应用层协议，定义的是传输的数据内容的规范。HTTP协议是建立在TCP协议之上的，即HTTP协议中的数据是利用TCP协议传输的（默认端口80），所以支持HTTP也就一定支持TCP。

HTTP/3 竟然基于 UDP，HTTP 协议这些年都经历了啥？（讲述了HTTP/1、HTTP/2、HTTP/3的技术发展过程）
HTTP还可以基于QUIC协议传输（HTTP/3，QUIC协议是基于UDP协议的）。
Google 搞了一个基于 UDP 协议的 QUIC 协议，并且使用在了 HTTP/3 上，HTTP/3 之前名为 HTTP-over-QUIC，从这个名字中我们也可以发现，HTTP/3 最大的改造就是使用了 QUIC。

GET和POST的区别

GET：获取资源；POST：传输实体主体。

先下结论，GET 和 POST 方法没有实质区别，只是报文格式不同。
GET 和 POST 只是 HTTP 协议中两种请求方式，而 HTTP 协议是基于 TCP/IP 的应用层协议，无论 GET 还是 POST，用的都是同一个传输层协议，所以在传输上，没有区别。

报文格式上，不带参数时，最大区别就是第一行方法名不同：

• POST 方法请求报文第一行是这样的 POST /uri HTTP/1.1 \r\n
• GET 方法请求报文第一行是这样的 GET /uri HTTP/1.1 \r\n
  是的，不带参数时他们的区别就仅仅是报文的前几个字符不同而已。

带参数时报文的区别呢？ 在约定中，GET 方法的参数应该放在 url 中，POST 方法参数应该放在 body 中。
现在我们知道了两种方法本质上是 TCP 连接，没有差别，也就是说，如果我不按规范来也是可以的。我们可以在 URL 上写参数，然后方法使用 POST；也可以在 Body 写参数，然后方法使用 GET。当然，这需要服务端支持。

最直观的区别就是GET把参数包含在URL中，POST通过request body传递参数。 GET请求在URL中传送的参数是有长度限制的，而POST没有限制。对参数的数据类型，GET只接受ASCII字符，而POST没有限制。 GET比POST更不安全，因为参数直接暴露在URL上，所以不能用来传递敏感信息。（从传输角度，POST和GET都是不安全的。因为 HTTP 在网络上是明文传输的，只要在网络节点上捉包，就能完整地获取数据报文。要想安全传输，就只有加密，也就是 HTTPS。）

HTTP和HTTPS的关系

十分钟搞懂HTTP和HTTPS协议？
一般HTTP中存在如下问题：

• 请求信息明文传输，容易被窃听截取；
• 数据的完整性未校验，容易被篡改；
• 没有验证对方身份，存在冒充危险。

HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：一般理解为HTTP+SSL(Secure Socket Layer)/TLS(Transport Layer Security)，通过 SSL证书来验证服务器的身份，并为浏览器和服务器之间的通信进行加密。（TLS的前身是SSL）

HTTPS是HTTP协议的安全版本，HTTP协议的数据传输是明文的，是不安全的，HTTPS使用了SSL/TLS协议进行了加密处理。
http和https使用连接方式不同，默认端口也不一样，http是80，https是443。

https协议为什么安全？ -> HTTPS使用了SSL(安全套接字层)/TLS(传输层安全)协议进行了加密处理和认证以及完整性保护。
https的ssl连接过程 -> 通常HTTP直接和TCP通信。当使用SSL时，则演变成先和SSL通信，再由SSL和TCP通信。

如何判断服务器正确接收请求

• 返回的响应报文为200 OK。
• 返回5xx表示是服务端的内部错误。
• 返回4xx表示是客户端的错误，例如请求报文语法错误，没有权限访问资源，没有找到资源等。

持久连接和管线化（pipelining）、短连接和长连接（持久连接）

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

• 在HTTP 1.0中，客户端的每次请求都要求建立一次单独的连接，在处理完本次请求后，就自动释放连接。（短连接）
• 在HTTP 1.1中，则可以在一次连接中处理多个请求，并且多个请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求。（长连接/持久连接）

管线化方式发送HTTP请求：同时并发多个请求，不需要一个接着一个地等待响应，比持久连接还快。
管线化机制须通过持久连接（persistent connection）完成，仅HTTP/1.1支持此技术（HTTP/1.0不支持），并且只有GET和HEAD要求可以进行管线化，而POST则有所限制。此外，初次创建连接时也不应启动管线机制，因为对方（服务器）不一定支持HTTP/1.1版本的协议。

在使用长连接的情况下，当一个网页打开完成后，客户端和服务器之间用于传输HTTP数据的 TCP连接不会关闭，如果客户端再次访问这个服务器上的网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Apache）中设定这个时间。实现长连接要客户端和服务端都支持长连接。
HTTP协议的长连接和短连接，实质上是TCP协议的长连接和短连接。