计算机网络

刚入职的程序员小白
95 阅读13分钟

文章来源：baijiahao.baidu.com/s?id=171252…

OSI模型和TCP模型

  1. OSI 七层模型：大而全，但是比较复杂、而且是先有了理论模型，没有实际应用。
  2. TCP/IP 四层模型：是由实际应用发展总结出来的，从实质上讲，TCP/IP只有最上面三层，最下面一 层没有什么具体内容，TCP/IP参考模型没有真正描述这一层的实现。
  3. 五层模型：五层模型只出现在计算机网络教学过程中，这是对七层模型和四层模型的一个折中，既 简洁又能将概念阐述清楚。

image.png

TCP三次握手

来源：baijiahao.baidu.com/s?id=171252…

三次握手过程

image.png 三次握手（Three-way Handshake）指客户端和服务器建立一个TCP连接时，双方总共需要发送3个报文段。目的：确认双方的接收能力和发送能力是否正常；同时指定双方的初始化序列号（ISN）为后面的可靠性传送做准备。

刚开始服务端处于监听状态，进行三次握手由客户端主动发起：

  1. 第一次握手：客户端给服务端发一个 连接请求报文段，头部指明，以及初始化序列号 ISN（seq=x）。此报文段不能携带数据，但要消耗掉一个序号。随后客户端进入 SYN_SENT （同步发送）状态。
  2. 第二次握手：服务端收到客户端的 之后，向客户端发送连接确认报文段，头部指明，，确认号（ack）为x+1，并且也选择一个初始化序列号y。随后服务器进入 SYN_RCVD （同步接收）的状态。
  3. 第三次握手：客户端收到服务端的 之后，会向服务端回送一个确认报文段，头部指明，确认号ack=y+1，序号seq=x+1，该报文段可以携带数据，不携带数据则不消耗序号。随后客户端进入 ESTABLISHED （连接已建立）状态。待服务器收到客户端发送的 报文段也会进入 状态，完成三次握手。

三次握手为什么不能是两次？

首先需要明确：三次握手是为了让客户端和服务端确认对方的发送能力以及接受能力都是正常的。

第一次握手：客户端发送报文段，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发送报文段，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发送报文段，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

因此，改成两次握手，服务端不能确定发送端的接收能力是否正常。

什么是半连接队列？

服务器第一次收到客户端的之后，就会处于(同步接收) 状态，此时双方还没有完全建立其连接，服务器会把此种状态下请求连接放在一个队列里，我们把这种队列称之为半连接队列。

当然还有一个全连接队列，就是已经完成三次握手，建立起连接的就会放在全连接队列中。如果队列满了就有可能会出现丢包现象。

三次握手过程中可以携带数据吗？

第一次、第二次握手不可以携带数据，而第三次握手是可以携带数据的。

假如第一次握手可以携带数据的话，如果有人要恶意攻击服务器，那他每次都在第一次握手中的 中放入大量的数据，并疯狂重发。这会让服务器花费大量的内存空间来缓存这些报文段，这样服务器就更容易被攻击了。

对于第三次握手，此时客户端已经处于连接状态，他已经知道服务器的接收、发送能力是正常的了，所以可以携带数据是情理之中。

第三次握手失败怎么办？

客户端收到服务端的后，其状态变为，并会发送给服务端，准备发送数据了。如果此时在网络中丢失，并且超时，那么服务端会重新发送。如果重传指定次数之后仍然未收到客户端的，服务端将自动关闭这个连接。但是客户端认为这个连接已经建立，如果客户端向服务端发数据，服务端将以复位报文段响应，客户端方能感知到服务端的错误。

TCP四次挥手

  • 第一次挥手：客户端向服务端发送一个连接释放报文段，头部指明，序号seq=u。并停止发送数据，主动关闭连接。随后客户端进入 FIN_WAIT1 （终止等待1）状态，等待服务端的确认。
  • 第二次挥手：服务端收到客户端发来的后，回送 ，头部指明，确认号ack=u+1，序号seq=v，随后服务端进入 CLOSE_WAIT（关闭等待） 状态。客户端收到服务端的后，进入FIN_WAIT2（终止等待2）状态，等待服务端发出的。
  • 第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，向客户端发送，头部指明，，序号seq=w，确认号，随后服务端进入LAST_ACK（最后确认）状态，等待客户端的。
  • 第四次挥手：客户端收到之后，同样向服务端发出，头部指明，seq=u+1，ack=w+1，此时客户端进入 TIME_WAIT 状态。服务端收到客户端的之后，进入 CLOSED 状态。客户端必须经过 2*MSL 后才进入 状态。此时连接已经完全释放

如果已经建立了连接，但是客户端突然出现故障了怎么办？

设有一个保活计时器，服务器每收到一次客户端的TCP报文段后都会重新复位这个计时器，时间通常是设置为2小时。客户端如果出现故障若，导致服务端两小时都没有收到客户端的任何数据，服务器就会每隔75秒钟发送一个探测报文段，若一连发送10个探测报文段仍然没反应，服务器就认为客户端出了故障，接着就关闭连接。

TCP协议

TCP 和 UDP 的区别？

  • TCP面向连接（如打电话要先拨号建立连接）；UDP是无链接的，即发送数据之前不需要建立连接
  • TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达；UDP尽最大努力交付，即不保证可靠交付。
  • TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流；UDP是面向报文的
  • 每一条TCP连接只能是点到点的；UDP支持一对一，一对多，多对一和多对多的交互通信
  • TCP首部开销20字节；UDP的首部开销小，只有8字节
  • TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。

什么是 TCP 粘包问题？

粘包就是指发送方应用层交给发送的若干数据包经过传输到达接收方时合并粘成了一个数据包，出现粘包的原因是多方面的，可能是来自发送方，也可能是来自接收方。

造成TCP粘包的原因？

发送方原因：默认使用 Nagle算法，当应用层交付给发送的数据包过于小时，发送方会收集了多个较小的数据包进行合并发送，这将会发生粘包。

接收方原因：发送方发送数据很快，接收方缓冲区收到大量数据，但应用层取出数据的速度又太慢，造成多个数据包被缓存，应用层就有可能读取到多个首尾相接粘到一起的数据包。

如何处理粘包问题？

在应用层进行处理。如：

  1. 在应用层交给的每个数据包头部都添加长度字段，接收方应用层读取数据时根据数据包头部长度字段循环读取相应长度的内容；
  2. 将应用层交给的每个数据包的首、尾分别添加开始符、结束符。

HTTP协议

HTTP 协议由哪几部分组成？

  1. 请求协议信息由 4 部分组成：请求行、请求头、空行、请求体
  2. 响应协议信息也由 4 部分组成：状态行、响应头、空行、响应体

image.png

HTTP状态码？

  1. 1XX (Informational) : 接收的请求正在处理

    100 Continue ：表明请求到目前为止都处理的很正常，客户端可以继续发送请求或者忽略这个响应。

  2. 2XX (Success) : 请求正常处理完毕

    200 OK : 表示成功处理了请求。

  3. 3XX (Redirection) : 需要进行附加操作以完成请求

    301 Moved Permanently ：永久性重定向。

    302 Found ：临时性重定向。

  4. 4XX (Client Error) : 服务器无法处理请求

    403 Forbidden ：请求被服务器拒绝。

    404 Not Found : 服务器找不到请求的网页。

  5. 5XX (Server Error) : 服务器处理请求出错

    500 Internal Server Error ：服务器正在执行请求时发生错误。

状态码 301 和 302 的区别？

301: 表示永久重定向。

302: 表示临时重定向。 image.png

HTTP 请求方法了解哪些?

HTTP/1.0 定义了三种请求方法：GET, POST和 HEAD方法。

HTTP/1.1新增了：PUT、PATCH、DELETE、CONNECT、OPTIONS、TRACE共5种HTTP请求方法。

HTTP幂等性了解吗？

对于同一个系统，在同样条件下，一次请求和重复多次请求对服端资源的影响是一致的，就称该操作为幂等的。

HTTP常见幂等方法：GET、PUT、DELETE、

HTTP常见非幂等方法：POST、PATCH

GET 和 POST 的区别？

  1. 从功能上讲，GET一般用来从服务器上获取资源，POST 一般用来在服务器上新增资源；
  2. 从 REST服务角度上说，GET是幂等的，而 POST不是幂等的;
  3. 从请求参数形式上看，GET 请求的数据会附在 URL之后，POST请求会把提交的数据放置在是 HTTP请求报文的请求体中；
  4. 就安全性而言，POST的安全性要比 GET的安全性高，因为 GET 请求提交的数据将明文出现在 URL上，而且 POST请求参数则被包装到请求体中，相对更安全；
  5. 从请求的大小看，GET请求的长度受限于浏览器或服务器对 URL长度的限制，允许发送的数据量比较小，而 POST请求理论上是没有大小限制。

image.png

怎么知道 HTTP 的报文长度?

当传输的是静态文件时，服务端能够很清楚的知道将要响应内容的大小，可以通过响应头中的Content-Length 域来告诉客户端报文的长度。如果服务端预先不知道将要响应内容的大小（动态生成的页面）就需要在响应头中指明 Transfer-Encoding: chunked。表示响应体是使用chunked分块方式拼接成的，不需要Content-Length指明长度。每一个分块包含十六进制的长度值和数据，最后一个分块长度值为0，表示实体结束，客户端可以以此为标志确认数据已经接收完毕。

image.png

Keep-Alive（长连接） 和 非 Keep-Alive 区别？

可以通过请求头或响应头中的Connection域查看是否是Keep-Alive。

短连接：在HTTP/1.0中默认使用短连接（也支持长连接，得手动设置Connection: keep-alive）。客户端每个HTTP请求和响应都会开启和关闭一个单独的TCP连接。

长连接： 而从HTTP/1.1起，默认使用长连接。同一个客户端和服务端之间的连续的多个HTTP请求和响应可以通过一个TCP连接来完成。但是一个长连接也不是一直保持，客户端在最后一个请求时，发送Connection: close，明确要求服务器关闭TCP连接，也可以通过 keep-alive timeout 参数来设置。

HTTP1.0、HTTP1.1、HTTP2的主要变化？

image.png image.png

HTTP 和 HTTPS 的主要区别？

端口：HTTP协议端口为80，HTTPS协议端口为443;

安全性：HTTP信息是明文传输；而HTTPS协议的信息是经过SSL/TLS协议加密后传输的。

数字证书：HTTPS协议需要到CA (Certificate Authority)机构申请数字证书，绝大多数需要花钱申请。

响应速度和资源消耗：HTTPS相比 HTTP在 TCP之上多了SSL/TLS 协议，因此响应速度会更慢，资源消耗会更多。

image.png

Cookie是什么？

HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上

Session是什么？

由于HTTP协议是无状态的协议，所以服务器需要记录用户状态时就需要借助Session机制。目前Session常见实现要借助Cookie，即服务器端创建一个Session对象，同时会创建一个特殊的Cookie对象（name为"JSESSIONID"，value为Session对象的ID），然后将该Cookie对象发送至浏览器。当浏览器端发送第N（N>1）次请求到同一服务器时就会携带该name为JSESSIONID的Cookie对象。服务器根据name为JSESSIONID的Cookie的value(sessionId)去查询对应Session对象，从而区分不同用户。(Session对象默认存活30分钟)

Cookie和Session的区别？

  1. 作用范围不同，Cookie保存在客户端（浏览器），Session保存在服务器端。
  2. 存取方式的不同，Cookie只能保存 ASCII编码的字符，Session可以存任意数据类型
  3. 有效期不同，Cookie可设置为长时间保持，比如我们经常使用的默认登录功能，Session一般失效时间较短，客户端关闭或者 Session超时都会失效(Session对象默认存活30分钟)。
  4. 隐私策略不同，Cookie存储在客户端，比较容易遭到不法获取；Session存储在服务端，安全性相对 Cookie要好一些。
  5. 存储大小不同， 单个 Cookie保存的数据量 <= 4KB；对于Session来说并没有上限，但出于对服务器端的性能考虑，Session内不要存放过多的东西，并且应设置Session删除机制。

SSL加密解密（SSL握手）：

image.png

强缓存和协商缓存：

原文件：www.mobiletrain.org/about/BBS/1… zhuanlan.zhihu.com/p/390170932

1. 强缓存(Expires和Cache-Control)：

  • Expires：通过设置Expires响应头，服务器告诉浏览器资源的过期时间。当浏览器发起请求时，如果本地缓存未过期，浏览器将直接使用缓存副本，而无需再次请求服务器。

  • Cache-Control：通过设置Cache-Control响应头，服务器可以提供更精确的缓存控制。常见的Cache-Control指令包括max-age、public、private、no-cache和no-store等。例如，设置max-age=3600表示资源在3600秒内有效，浏览器可以直接使用缓存。

2. 协商缓存(Last-Modified和ETag)：

  • Last-Modified：服务器在响应头中返回资源的最后修改时间(GMT格式)。当浏览器再次请求资源时，通过If-Modified-Since请求头将上次的最后修改时间发送给服务器。如果资源的最后修改时间与服务器上的相同，服务器返回304 Not Modified响应，告诉浏览器可以使用缓存副本。

  • ETag：服务器在响应头中返回资源的唯一标识符(通常是哈希值)。当浏览器再次请求资源时，通过If-None-Match请求头将上次的ETag发送给服务器。如果资源的ETag与服务器上的相同，服务器返回304 Not Modified响应，告诉浏览器可以使用缓存副本。

在实际应用中，浏览器首先检查强缓存信息(Expires和Cache-Control)，如果缓存仍然有效，则直接使用缓存。如果缓存已过期，浏览器发送带有协商缓存信息(Last-Modified和ETag)的请求到服务器进行验证。如果服务器返回304 Not Modified响应，则浏览器使用缓存;否则，服务器返回新的资源内容。

3.为什么要有etag？

你可能会觉得使用last-modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要etag呢？HTTP1.1中etag的出现（也就是说，etag是新增的，为了解决之前只有If-Modified的缺点）主要是为了解决几个last-modified比较难解决的问题：

  1. 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新get；

  2. 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，if-modified-since能检查到的粒度是秒级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；

  3. 某些服务器不能精确的得到文件的最后修改时间。

avatar
文章
阅读
粉丝