计算机网络的相关知识

最新推荐文章于 2024-05-30 21:45:08 发布

minastinis of king

最新推荐文章于 2024-05-30 21:45:08 发布

阅读量158

点赞数 2

分类专栏： JAVA学习找工作

本文链接：https://blog.csdn.net/qq_40971025/article/details/118458272

版权

JAVA学习同时被 2 个专栏收录

36 篇文章 1 订阅

订阅专栏

找工作

20 篇文章 0 订阅

订阅专栏

1. OSI与TCP/IP各层的结构与功能，都有哪些协议？

五层协议结构：物理层、链路层、网络层、运输层、应用层

1.1 应用层

通过同一台主机应用进程间的交互来完成也定网络应用，其中包括域名系统DNS协议、支持万维网应用的HTTP协议、支持电子邮件的SMTP协议。

1.2 运输层

负责两台主机进程之间的通信提供通用的数据传输服务，也就是解决不同台主机应用进程间的交互，主要包含传输控制协议TCP以及用户数据协议UDP

1.3 网络层

负责不同主机间的逻辑通信，网络层的任务就是选择合适的网件路由和交换节点，确保数据即使传送。在发送数据时，网络层把运输层产生的报文段或用户数据封装成分组和包进行传送。在TCP/IP体系结构中，由于网络层使用IP协议，因此分组也叫IP数据报，简称数据报。

网络层不提供服务质量的承诺，不保证分组交付的时限所传送的分组可能出错，丢失，重复和失序。进程之间通信的可靠性由运输层负责

地址解析协议 ARP 把 IP 地址解析为硬件地址。ARP 的高速缓存可以大大减少网络上的通信量。因为这样可以使主机下次再与同样地址的主机通信时，可以直接从高速缓存中找到所需要的硬件地址而不需要再去广播方式发送 ARP 请求分组

那么这个时候就有疑问了，运输层和网络层负责的都是两个主机之间的相关通信，它们的区别究竟在哪里？
这里有一个形象的解释：https://www.cnblogs.com/sea-stream/p/10799013.html
我们只需要记住：传输层协议将应用进程的消息传送到网络边缘(也就是网络层)，但是它并不涉及消息是如何在网络层之间传送的工作，真正负责这个传输的是网络层。

1.4 数据链路层

数据链路层提供直连两个设备之间的通信功能。因此，仔细观察世界的网络可以发现，这些都是由很多很多这样的数据链路组成的，在一段段的链路上传送时，就需要使用专门的链路层协议实现相邻两个节点的数据传输。每一帧包括数据和必要的控制信息（如同步信息，地址信息，差错控制等）。主要有PPP协议，即用户计算机和ISP进行通信时所使用的数据链路协议；还有ARP协议，用于将IP地址转换为MAC地址。

网络的IP就负责没有直连的两个网络之间的传输。而只是告诉你下一步可以怎么走。
数据链路层的三个基本问题：封装成帧，透明传输和差错控制
循环冗余检验CRC是一种检错方法
PPPoE 是为宽带上网的主机使用的链路层协议
链路层只有两种方式：点对点通信与广播通信
用于减少碰撞采用的是载波监听多点接入CSMA/CD
以太网的适配器具有过滤功能，它只接收单播帧，广播帧和多播帧。

1.5 物理层

是实现相邻计算机节点之间比特流的透明传送，尽可能屏蔽掉具体传输介质和物理设备的差异，使其上面的数据链路层不必考虑网络的具体传输介质是什么。

这里有一个链接，说明了传输层、网络层、链路层、物理层这四层之间的关系：
https://www.zhihu.com/question/29949319/answer/46248356
这里还有一个视频是从设计的角度讲为什么会分层，怎么再分层中处理各种不同问题的视频：
https://www.bilibili.com/video/BV1o4411m7XA?from=search&seid=6529467829821327218

还有这个大图看看就得了，里面常用的协议记一记：
在这里插入图片描述

2. TCP与UDP

2.1三次握手与四次挥手

在这里插入图片描述

为什么要三次握手？

为了确认双方都收发正常

第一次，Client什么都确认不了，Server确认了对方发送正常，自己接收正常
第二次，Client确认了自己发送、接收正常，对方发送、接收正常，Server保持上一步
第三次，Client都已经确认完了，Server又新确认了对方接收正常以及自己发送正常。

有了SYN为什么还要法ACK?

这和Client给Server发ACK一样，是为了让服务器在第三部时确认自己的发送是正常的以及对方的接收是正常的。即保证了服务器到客户端通信的正常。而发送ACK是保证了客户端到服务器的正常。

为什么要四次挥手?

客户端发送一个FIN，用来关闭客户端到服务器的数据传输
服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1。
服务器关闭与客户端的连接，发送一个FIN给客户端
客户端发回ACK报文确认，并将确认序号设置为收到序号加1。
举个例子：A 和 B 打电话，通话即将结束后，A 说“我没啥要说的了”，B回答“我知道了”，但是 B 可能还会有要说的话，A 不能要求 B 跟着自己的节奏结束通话，于是 B 可能又巴拉巴拉说了一通，最后 B 说“我说完了”，A 回答“知道了”，这样通话才算结束。

2.2 TCP与UDP的区别

在这里插入图片描述
应用场景上，UDP比较适合那种对效率要求比较高的通信场景，比如在线视频以及语音，这样即使有丢包影响也不是太大，TCP比较适合对可靠性要求比较高的比如文件传输、发送和接收邮件、远程登录等场景。

2.3 TCP如何保证可靠传输？

有效分割
校验和
流量控制：使用的是滑动窗口协议，当接收方来不及处理发送方的数据，可以提示发送方降低发送速率。
重复丢弃
拥塞控制（利用滑动窗口）
ARQ协议：每发完一个分组就停止发送，等待对法确认，在收到确认之后再发下一个分组
超时重传

2.4 ARQ协议

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

2.4.1 停止等待ARQ

含义：
是指在发送一个分组就停止发送，等待着接收方发送确认帧，如果一段时间没有收到确认帧就重复发送这个分组，知道收到确认帧才发送下一个数据分组。如果接收方接受到了重复的分组，那么就抛弃该分组，但同时需要向发送方发送确认帧。

优缺点：

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

几种情况的处理方式：

1）无差错情况：不用多说
2）出现差错情况：不用说
3）确认丢失与确认迟到（这是两种差错的特殊情况）
确认丢失：确认消息在传输过程丢失。当A发送M1消息，B收到后，B向A发送了一个M1确认消息，但却在传输过程中丢失。而A并不知道，在超时计时过后，A重传M1消息，B再次收到该消息后采取以下两点措施：1. 丢弃这个重复的M1消息，不向上层交付。 2. 向A发送确认消息。（不会认为已经发送过了，就不再发送。A能重传，就证明B的确认消息丢失）。
确认迟到：确认消息在传输过程中迟到。A发送M1消息，B收到并发送确认。在超时时间内没有收到确认消息，A重传M1消息，B仍然收到并继续发送确认消息（B收到了2份M1）。此时A收到了B第二次发送的确认消息。接着发送其他数据。过了一会，A收到了B第一次发送的对M1的确认消息（A也收到了2份确认消息）。处理如下：1. A收到重复的确认后，直接丢弃。2. B收到重复的M1后，也直接丢弃重复的M1。

2.4.2 连续ARQ协议

连续 ARQ 协议可提高信道利用率。发送方维持一个发送窗口，凡位于发送窗口内的分组可以连续发送出去，而不需要等待对方确认。接收方一般采用累计确认，对按序到达的最后一个分组发送确认，表明到这个分组为止的所有分组都已经正确收到了。
优缺点：
优点：信道利用率高，容易实现，即使确认丢失，也不必重传。
缺点：不能向发送方反映出接收方已经正确收到的所有分组的信息。比如：发送方发送了 5条消息，中间第三条丢失（3号），这时接收方只能对前两个发送确认。发送方无法知道后三个分组的下落，而只好把后三个全部重传一次。这也叫 Go-Back-N（回退 N），表示需要退回来重传已经发送过的 N 个消息。

2.5 滑动窗口和流量控制

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

2.6 拥塞控制

拥塞控制就是为了防止过多的数据注入到网络中，这样就可以使网络中的路由器或链路不致过载。
拥塞控制与流量控制的区别：

拥塞控制所要做的都有一个前提，就是网络能够承受现有的网络负荷。拥塞控制是一个全局性的过程，涉及到所有的主机，所有的路由器，以及与降低网络传输性能有关的所有因素。
相反，流量控制往往是点对点通信量的控制，是个端到端的问题。

2.6.1 拥塞控制四种算法

慢开始、拥塞避免、快重传和快恢复

慢开始：逐倍增加拥塞窗口的大小
拥塞避免：缓慢增加拥塞窗口的大小，每次加1

3. Http的相关知识

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

在这里插入图片描述

上图有一个错误，请注意，是OSPF不是OPSF。 OSPF（Open Shortest Path First，ospf）开放最短路径优先协议,是由Internet工程任务组开发的路由选择协议

总体来说主要有以下几个阶段：

DNS解析
建立TCP连接
发送HTTP请求
服务器处理请求并返回HTTP报文
浏览器解析渲染页面
连接结束

3.2 状态码

在这里插入图片描述

3.3 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协议的长连接和短连接，实质上是TCP协议的长连接和短连接。

3.4 HTTP是不保存状态的协议，如何保存用户的状态？

通常会使用Session来保存用户状态，典型的就是购物车的场景。一般情况下，服务器会在一定时间内保存这个 Session，过了时间限制，就会销毁这个Session。
在服务端保存 Session 的方法很多，最常用的就是内存和数据库(比如是使用内存数据库redis保存)。

既然 Session 存放在服务器端，那么我们如何实现 Session 跟踪呢？
大部分情况下，我们都是通过在 Cookie 中附加一个 Session ID 来方式来跟踪。

Cookie 被禁用怎么办?
最常用的就是利用 URL 重写把 Session ID 直接附加在URL路径的后面。

3.4.1 Cookie的作用以及Session和Cookie的区别

Cookie主要用来保存用户信息，比如在你需要登录的时候，提前就将一些你需要输入的信息自动显示出来，Seesion主要是用来保存用户状态，比如登录状态，典型的场景就是购物车，为了跟踪用户的购物状态。
注意Cookie只能够存String类型的数据，而Seesion中啥类型的数据都能存。
Cookie 数据保存在客户端(浏览器端)，Session 数据保存在服务器端。
Cookie 存储在客户端中，而Session存储在服务器上，相对来说 Session 安全性更高。如果要在 Cookie 中存储一些敏感信息，不要直接写入 Cookie 中，最好能将 Cookie 信息加密然后使用到的时候再去服务器端解密。

后来查了一下资料，购物车这种东西因为比较简单，而我们的session和cookie都是可以自己定义的，所以都可以实现购物车，不过为了保护隐私数据，最好采用session来做这个功能：
Session和Cookie实现购物车

3.5 HTTP1.0和HTTP1.1的主要区别

长连接 : 在HTTP/1.0中，默认使用的是短连接，也就是说每次请求都要重新建立一次连接。HTTP 是基于TCP/IP协议的,每一次建立或者断开连接都需要三次握手四次挥手的开销，如果每次请求都要这样的话，开销会比较大。因此最好能维持一个长连接，可以用个长连接来发多个请求。HTTP 1.1起，默认使用长连接 ,默认开启Connection： keep-alive。 HTTP/1.1的持续连接有非流水线方式和流水线方式。流水线方式是客户在收到HTTP的响应报文之前就能接着发送新的请求报文。与之相对应的非流水线方式是客户在收到前一个响应后才能发送下一个请求。
错误状态响应码 :在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除。
缓存处理 :在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
带宽优化及网络连接的使用 :HTTP1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了，并且不支持断点续传功能，HTTP1.1则在请求头引入了range头域，它允许只请求资源的某个部分，即返回码是206（Partial Content），这样就方便了开发者自由的选择以便于充分利用带宽和连接。

3.6 URI和URL的区别

URI(Uniform Resource Identifier) 是统一资源标志符，可以唯一标识一个资源。
URL(Uniform Resource Location) 是统一资源定位符，可以提供该资源的路径。它是一种具体的 URI，即 URL 可以用来标识一个资源，而且还指明了如何 locate 这个资源。
URI的作用像身份证号一样，URL的作用更像家庭住址一样。URL是一种具体的URI，它不仅唯一标识资源，而且还提供了定位该资源的信息。

3.7 HTTP和HTTPS的区别

端口：HTTP的URL由“http://”起始且默认使用端口80，而HTTPS的URL由“https://”起始且默认使用端口443。
安全性和资源消耗： HTTP协议运行在TCP之上，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份。HTTPS是运行在SSL/TLS之上的HTTP协议，SSL/TLS 运行在TCP之上。所有传输的内容都经过加密，加密采用对称加密，但对称加密的密钥用服务器方的证书进行了非对称加密。所以说，HTTP 安全性没有 HTTPS高，但是 HTTPS 比HTTP耗费更多服务器资源。
对称加密：密钥只有一个，加密解密为同一个密码，且加解密速度快，典型的对称加密算法有DES、AES等；
非对称加密：密钥成对出现（且根据公钥无法推知私钥，根据私钥也无法推知公钥），加密解密使用不同密钥（公钥加密需要私钥解密，私钥加密需要公钥解密），相对对称加密速度较慢，典型的非对称加密算法有RSA、DSA等。