计算机基础------计算机网络

#HashMap#

已于 2023-04-25 14:26:24 修改

阅读量5k

点赞数 12

文章标签：网络 tcp/ip http

于 2022-02-27 19:24:53 首次发布

liaozhongmin

本文链接：https://blog.csdn.net/weixin_46345400/article/details/123155610

版权

一.OSI与TCP/IP各层的结构与功能,都有哪些协议?

watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMjcyMTcw,size_16,color_FFFFFF,t_70

数据传输过程

watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMjcyMTcw,size_16,color_FFFFFF,t_70

数据封装过程

watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMjcyMTcw,size_16,color_FFFFFF,t_70

解封装过程

watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQzMjcyMTcw,size_16,color_FFFFFF,t_70

二.TCP 三次握手和四次挥手

三次握手

过程：客户端请求服务端连接，此时发送一个带有SYN=1标志的请求，同时随机生成一个seq序列号，当服务端收到之后会发送一个确认标志ACK=1，确认序号ack(客户端seq+1)，同时发送一个SYN=1的标志以及seq序列号给客户端，这时对于客户端来说，收发消息都没问题，但是对于服务端来说，只是收到客户端的消息，还不能确认客户端是否能收到消息，此时就需要第三次握手，客户端发送ACK确认标志以及确认序号ack，这就说明客户端收到了服务端发来的消息。

四次挥手

watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAI0hhc2hNYXAj,size_20,color_FFFFFF,t_70,g_se,x_16

过程：客户端发送一个FIN=1的标志以及序列号seq给服务端，这时候服务端也许还有数据要发，只是给客户端发送一个确认标志ACK和ack序列号，等发完了或者服务端想断开时，服务端会发送一个FIN=1标志以及seq序列号给客户端，接着客户端需要发送一个确认标志ACK=1和ack确认号给服务端，来告诉服务端我收到了你的消息，最后断开连接

三.TCP和UDP的区别

TCP报文

UDP报文

watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAI0hhc2hNYXAj,size_20,color_FFFFFF,t_70,g_se,x_16

四.TCP 协议如何保证可靠传输

1)应用数据被分割成 TCP 认为最适合发送的数据块。(把数据分割成段)

2)TCP 给发送的每⼀个包进行编号，接收方对数据包进行排序，把有序数据传送给应用层。

3)校验和：TCP 将保持它首部和数据的检验和。这是⼀个端到端的检验和，目的是检测数据在传输过程中的任何变化。如果收到段的检验和有差错，TCP 将丢弃这个报文段和不确认收到此报文段。

4)TCP 的接收端会丢弃重复的数据。

5)流量控制：TCP 连接的每⼀方都有固定大小的缓冲空间，TCP的接收端只允许发送端发送接收端缓冲区能接纳的数据。当接收方来不及处理发送方的数据，能提示发送方降低发送的速率，防止包丢失。TCP 使用的流量控制协议是可变大小的滑动窗口协议。（TCP 利用滑动窗口实现流量控制）

6)拥塞机制：当网络拥塞时，减少数据的发送。

7)ARQ协议：也是为了实现可靠传输的，它的基本原理就是每发完⼀个分组就停止发送，等待对方确认。在收到确认后再发下一个分组。

8)超时重传：当 TCP 发出⼀个段后，它启动⼀个定时器，等待目的端确认收到这个报文段。如果不能及时收到⼀个确认，将重发这个报文段。

发送数据时可能遇到的情况：

1) 无差错情况：发送方发送分组,接收方在规定时间内收到,并且回复确认.发送方再次发送。

2) 出现差错情况（超时重传）：停止等待协议中超时重传是指只要超过⼀段时间仍然没有收到确认，就重传前面发送过的分组（认为刚才发送过的分组丢失了）。因此每发送完⼀个分组需要设置⼀个超时计时器，其重传时间应比数据在分组传输的平均往返时间更长⼀些。这种自动重传方式常称为自动重传请求 ARQ 。另外在停止等待协议中若收到重复分组，就丢弃该分组，但同时还要发送确认。

3) 确认丢失：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了⼀个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）

4）确认迟到：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第⼆次发送的确认消息。接着发送其他数据。过了⼀会，A收到了B第⼀次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

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

停止等待ARQ协议

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

2)在停止等待协议中，若接收方收到重复分组，就丢弃该分组，但同时还要发送确认；

优点：简单

缺点：信道利用率低，等待时间长

连续ARQ协议

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

优点：信道利用率高，容易实现，即使确认丢失，也不必重传

缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

五.滑动窗口和流量控制

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

六.拥塞控制

在某段时间，若对网络中某⼀资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫拥塞。拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。拥塞控制所要做的都有⼀个前提，就是网络能够承受现有的网络负荷。拥塞控制是⼀个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。相反，流量控制往往是点对点通信量的控制，是个端到端的问题。流量控制所要做到的就是抑制发送端发送数据的速率，以便使接收端来得及接收。

为了进行拥塞控制，TCP 发送方要维持⼀个拥塞窗口(cwnd) 的状态变量。拥塞控制窗口的大小取决于网络的拥塞程度，并且动态变化。发送方让自己的发送窗口取为拥塞窗口和接收方的接受窗口中较小的⼀个。

TCP的拥塞控制采用了四种算法，即慢开始、拥塞避免、快重传和快恢复。

慢开始：慢开始算法的思路是当主机开始发送数据时，如果立即把大量数据字节注入到网络，那么可能会引起网络阻塞，因为现在还不知道网络的符合情况。经验表明，较好的方法是先探测⼀下，即由小到大逐渐增大发送窗口，也就是由小到大逐渐增大拥塞窗口数值。 cwnd初始值为1，每经过⼀个传播轮次，cwnd加倍。

拥塞避免：拥塞避免算法的思路是让拥塞窗口cwnd缓慢增大，即每经过⼀个往返时间RTT就把发送放的cwnd加1

快重传与快恢复：在 TCP/IP 中，快速重传和恢复（fast retransmit and recovery，FRR）是⼀种拥塞控制算法，它能快速恢复丢失的数据包。没有 FRR，如果数据包丢失了，TCP 将会使用定时器来要求传输暂停。在暂停的这段时间内，没有新的或复制的数据包被发送。有了 FRR，如果接收机接收到⼀个不按顺序的数据段，它会立即给发送机发送⼀个重复确认。如果发送机接收到三个重复确认，它会假定确认件指出的数据段丢失了，并立即重传这些丢失的数据段。有了 FRR，就不会因为重传时要求的暂停被耽误。当有单独的数据包丢失时，快速重传和恢复（FRR）能最有效地工作。当有多个数据信息包在某⼀段很短的时间内丢失时，它则不能很有效地工作。

七.在浏览器中输入url地址 ->> 显示主页的过程

watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAI0hhc2hNYXAj,size_20,color_FFFFFF,t_70,g_se,x_16

总结：

1. DNS解析

2. TCP连接

3. 发送HTTP请求

4. 服务器处理请求并返回HTTP报文

5. 浏览器解析渲染页面

6. 连接结束

八.状态码

watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBAI0hhc2hNYXAj,size_20,color_FFFFFF,t_70,g_se,x_16

九.各种协议与HTTP协议之间的关系

首先发给DNS服务器，进行域名解析，得到IP地址后生成针对目标Web服务器的HTTP请求报文，然后报文由TCP协议负责传输，为了方便通信，HTTP请求报文被分为报文段，然后每个报文段可靠的传输给对方，然后报文段由IP层负责一边中转一遍传送，服务器收到报文段后重组报文段，然后由应用层的HTTP协议处理请求的内容，请求的结果以同样的方式进行回传。

十.HTTP长连接,短连接

在HTTP/1.0中默认使用短连接。也就是说，客户端和服务器每进行一次HTTP操作，就建立一次连接，任务结束就中断连接。当客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源（如JavaScript文件、图像文件、CSS文件等），每遇到这样⼀个Web资源，浏览器就会重新建立一个HTTP会话。

从HTTP/1.1起，默认使用长连接，用以保持连接特性。使用长连接的HTTP协议，会在响应头加⼊这行代码：

connection:keep-alive

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

十一.HTTP是不保存状态的协议,如何保存用户状态?

HTTP 是⼀种不保存状态，即无状态（stateless）协议。也就是说 HTTP 协议自身不对请求和响应之间的通信状态进行保存。那么我们保存用户状态呢？Session 机制的存在就是为了解决这个问题，Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为 HTTP 协议是无状态的。服务端给特定的用户创建特定的 Session 之后就可以标识这个用户并且跟踪这个用户了（一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session）。在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？⼤部分情况下，我们都是通过在 Cookie 中附加⼀个 Session ID 来方式来跟踪。 Cookie 被禁用怎么办? 最常用的就是利用URL 重写把 Session ID 直接附加在URL路径的后面

十二.Cookie的作用是什么?和Session有什么区别？

Cookie ⼀般用来保存用户信息比如①我们在 Cookie 中保存已经登录过得用户信息，下次访问网站的时候页面可以自动帮你登录的⼀些基本信息给填了；②⼀般的网站都会有保持登录也就是说下次你再访问网站的时候就不需要重新登录了，这是因为用户登录的时候我们可以存放了⼀个 Token 在 Cookie 中，下次登录的时候只需要根据 Token 值来查找用户即可(为了安全考虑，重新登录一般要将Token重写)；③登录⼀次网站后访问网站其他页面不需要重新登录。Session 的主要作用就是通过服务端记录用户的状态。典型的场景是购物车，当你要添加商品到购物车的时候，系统不知道是哪个用户操作的，因为HTTP 协议是无状态的。服务端给特定的⽤户创建特定的Session之后就可以标识这个用户并且跟踪这个用户了。

总结区别：

1)Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。

2)Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储⼀些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

十三.URI和URL的区别是什么?

URI(Uniform Resource Identifier) 是统⼀资源标志符，可以唯⼀标识⼀个资源。 URL(Uniform Resource Location) 是统⼀资源定位符，可以提供该资源的路径。它是⼀种具体的 URI，即 URL 可以⽤来标识⼀个资源，而且还指明了如何 locate 这个资源。

URI的作用像身份证号⼀样，URL的作用更像家庭住址⼀样。URL是⼀种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

十四.HTTP 和 HTTPS 的区别？

1. 端口：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。

2. 安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在 TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。

对称加密：密钥只有⼀个，加密解密为同⼀个密码，且加解密速度快，典型的对称加密算法有DES、AES等；

非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等

十五.HTTP 1.0和HTTP 1.1的主要区别是什么?

1. 长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立⼀次连接。 HTTP 是基于TCP/IP协议的,每⼀次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持⼀个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1 的持续连接有非流水线方式和流水线方式。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前⼀个响应后才能发送下⼀个请求。

2. 错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。

3. 缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。

4. 带宽优化及网络连接的使用 :HTTP1.0中，存在⼀些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。