计算机网络总结

是阿ciu

已于 2024-01-08 10:32:10 修改

阅读量567

点赞数

文章标签：计算机网络网络网络协议

于 2022-10-16 16:11:06 首次发布

本文链接：https://blog.csdn.net/IDEA_guo/article/details/127348879

版权

说一下OSI七层模型

在这里插入图片描述

https://www.nowcoder.com/questionTerminal/3304a662ee214d27aff31738ad5bada8?from=2021dituibook

应用层（报文）

定义了应用进程间通信和交互的规则。
如支持万维网的Http协议、支持电子邮件的SMTP协议、支持文件传送的FTP协议

表示层

数据压缩、加密以及数据描述

会话层

建立会话

运输层（报文段）

运输层的任务是负责向两个计算机中进程之间的通信提供一种通用的数据传输服务，应用层通过运输层可以传输报文。
识别并将数据报正确交付相应的应用程序（也就是进程），识别数据报属于哪个应用程序的方法为看端口；
TCP可靠传输，UDP不可靠传输；

在这里插入图片描述

网络层（包/ip数据报）

负责不相邻的两个节点间的通信，比如我的电脑和网页服务器之间的通信
网络层将运输层产生的报文段或者用户数据报封装成分组或者包（packet）进行传送。由于网络层使用IP协议，所以分组或包（packet）也叫IP数据报
用IP地址识别源地址和目的地址，并确定转发路线，使效率最高；

在这里插入图片描述

数据链路层（帧）

负责相邻设备间通信，两个节点传输数据时，链路层将网络层交下来的数据报组装成帧，在链路上传送帧。
具体表现为点对点通信和广播通信
数据链路层(交换机)根据下一跳IP地址就能确定下一跳的MAC地址，并将网络层数据报再次封装，加上目的MAC地址，交由物理层传送
负责帧的差错检测，丢弃错误的帧

在这里插入图片描述

物理层（比特流）

考虑的是怎样在传输媒体上传输数据比特流，而不是指具体的传输媒体。

在这里插入图片描述

ARP协议

ARP 实现由 IP 地址得到 MAC 地址。

TCP和UDP的区别

TCP

传输控制协议 TCP是面向连接的，需要三次握手建立连接和四次挥手释放连接
每一条 TCP 连接只能有两个端点，只能是一对一通信
提供可靠的数据传输服务
面向字节流，把应用层传下来的报文看成字节流
有流量控制，拥塞控制，提供全双工通信

UDP

用户数据报协议 UDP是无连接的
支持一对一、一对多、多对一和多对多的交互通信。
尽最大可能交付，不可靠传输，不使用流量控制和拥塞控制
面向报文

TCP 主要提供完整性服务，UDP 主要提供及时性服务。

说一下UDP的首部格式

首部字段有8个字节，包括源端口、目的端口、长度、校验和。
12个字节的伪首部是为了计算校验和临时添加的

说一下TCP的首部格式

（至少20个字节）

序号：对字节流进行编号。例如序号为301，如果携带的数据长度为100字节，那下一个数据报序号为401
确认号：期望收到的下个报文的序号
数据偏移：首部的长度（数据部分距离报文段起始处的偏移量）
确认ACK：当ACK=1时确认号字段有效，否则无效。（TCP规定，在连接建立后所有传送的报文段都必须把ACK置1）
同步SYN：在连接建立时用来同步序号。（当SYN=1，ACK=0时表示这是一个连接请求报文段。若对方同意建立连接，则响应报文中是SNY=1，ACK=1）
终止FIN：当FIN=1时，表示此报文段的发送方数据已发送完毕，并要求释放连接。
窗口值：窗口值是告诉对方接收方允许接收的数据量

在这里插入图片描述

说一下TCP三次握手

第一次握手：客户端向服务端发送请求报文，序号seq=x，SYN=1，ACK=0。第一次握手前客户端的状态为close，第一次握手后客户端的状态为SYN-SENT，服务端的状态为Listen。
第二次握手：服务端收到连接请求报文，则向客户端发送连接确认报文，序列号seq为y，SYN=1，ACK=1，确认号为x+1。第二次握手后服务端的状态为SYN-RCVD，此时客户端的状态依旧是SYN-SENT。
第三次握手：客户端收到服务端的连接确认报文后，向服务端发出确认，序号为x+1，ack=1，确认号为y+1，第三次握手后客户端和服务端的状态都为established，此时连接建立完成。

在这里插入图片描述

为什么三次握手/两次握手可以吗

第三次握手主要是为了防止失效的连接请求到达服务器，让服务器错误打开连接。

如果不采用三次握手，只要服务端发出确认就建立起连接，此时客户端不会向服务端响应也不会发送数据，服务端就一直等待客户端，浪费资源。

说一下TCP四次挥手

客户端向服务端发送连接释放报文FIN=1。并停止发送数据，进入FIN-WAIT-1（终止等待1）状态，等待B确认
服务端收到连接释放报文后发出确认报文段，服务端进入CLOSE-WAIT（关闭等待）状态，此时的TCP处于半关闭状态，客户端到服务端的连接释放。（B能向A发送数据但是A不能向B发送数据）
A收到B的确认后，进入FIN-WAIT-2（终止等待2）状态，等待B发送连接释放报文
B发送完数据，不再需要连接时，就会发出连接释放报文段，B进入LAST-ACK（最后确认）状态，等待A的确认
A收到B的连接释放报文段后，对此发出确认报文段，A进入TIME-WAIT（时间等待）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL（最大报文存活时间）后，A才进入CLOSED状态。B收到A发送的确认报文段后关闭连接，若未收到，那B会重新发送连接释放报文。

在这里插入图片描述

四次挥手的原因

客户端发送了FIN连接释放报文后，服务器收到这个报文后发送确认报文，进入close-wait状态，这状态就是让服务器端发送还未传送完毕的数据。等服务器端传送完数据后，服务器才会发送FIN连接释放报文，故需要四次挥手。

TIME_WAIT为什么是2msl（2分钟）

保证A发送的最后一个确认报文能够送达。如果B收不到A发送的确认报文，那么就会重新发送连接释放报文，A等待一段时间就是为了处理这种情况
等待2msl是为了让本连接中所有报文段从网络中消失，使得下一个新的连接不会出现旧连接的请求报文段

TCP的可靠性体现在哪

首先，TCP 的连接是基于三次握手，而断开则是四次挥手。确保连接和断开的可靠性。
其次，TCP 的可靠性，还体现在 “有状态”

TCP 通过校验和（发送方与接收方的校验和进行比对，不相同则认为传输有误）

ACK 应答（通过与序列号配合保证数据按序到达、去除重复数据）

超时重传（当报文发出后在一定的时间内未收到接收方的确认，发送方就会进行重传）

来记录哪些数据发送了被接收，哪些没有被接收，并且保证数据包按序到达，保证数据传输不出差错。
再次，TCP 的可靠性，还体现在“可控制”

通过流量控制（滑动窗口）和拥塞控制来控制发送方发送速率。

TCP如何实现流量控制

接收方发送的确认报文中的窗口字段可以用来控制发送方窗口大小，从而实现流量控制。
还可将将窗口字段设置为 0，使发送方不能发送数据。

谈谈你对滑动窗口的理解

TCP利用滑动窗口实现流量控制的机制。
滑动窗口的大小意味着接收方还有多大的缓存区可以接收数据，发送方就可以以此来限制发送。当窗口值为0时意味着不能发送数据

TCP如何实现拥塞控制

拥塞控制是为了维护整个网络的性能，当检测到网络拥堵（丢包）时，发送方主动降低发送速率，减少网络中的负载。
这一点和流量控制很像，但是出发点不同，流量控制是为了让接收方来得及接收，而拥塞控制是为了降低整个网络的拥塞程度
TCP通过四个算法来进行拥塞控制：慢开始、拥塞避免、快重传、快恢复

慢开始

发送的最初执行慢开始，令拥塞窗口值cwnd为1，发送方只能发送一个报文段，当收到确认后，将cwnd加倍，后面能发送的数量为2/4/8…

拥塞避免

因为每轮窗口值都会翻倍，会使发送方的发送速度加快，导致拥塞的可能性增高。这个时候会设置一个慢开始门限（ssthresh）
当窗口值>=门限时，进入拥塞避免，每轮窗口值只+1
当出现超时时，会将慢开始门限（ssthresh）设置为当前cwnd的一半（cwnd/2），然后重新慢开始

快重传

在接收方，要求每次接收到报文段都应该对最后一个已收到的有序报文段进行确认。例如已经接收到 M1 和 M2，此时收到 M4，应当发送对 M2 的确认。
在发送方，如果收到三个重复确认，那么可以知道下一个报文段丢失，此时执行快重传，立即重传下一个报文段。例如收到三个 M2，则 M3 丢失，立即重传 M3。

快恢复

发送方一旦收到三个重复确认，就知道只是丢失了个别报文段，不算网络拥塞，于是不启动慢开始算法
而是执行快恢复算法。将窗口门限和窗口值都调成当前窗口的一半。直接进入拥塞避免。

ip地址有哪些分类

A类地址(1~126):网络号占前8位，以0开头，主机号占后24位。

B类地址(128~191):网络号占前16位，以10开头，主机号占后16位。

C类地址(192~223):网络号占前24位，以110开头，主机号占后8位。

在这里插入图片描述

POST和GET有哪些区别？各自应用场景？

使用场景

post是用于传输实体主体，get是用于获取资源

区别

Get请求参数通过URL传递，Post的参数是放在请求体中
get请求可以缓存，post请求不可缓存
get请求页面后退时，不产生影响。post请求页面后退时，会重新提交请求
Get产生一个TCP数据报，Post产生两个。对于Get方式请求，浏览器会把请求头和请求体一并发送出去。而对于Post，浏览器先发送请求头，服务器响应100 continue，浏览器再发送请求体。

在交互过程中如果数据传送完了，还不想断开连接怎么办，怎么维持？

在 HTTP 中响应体的 Connection 字段指定为 keep-alive

在浏览器中输入 URL地址到显示主页的过程

使用DNS解析域名获得相应的ip地址
获得ip地址后，找到相应的服务器，浏览器与服务器发起三次握手，建立TCP连接
TCP建立起连接后，浏览器向服务器发送http请求
服务器响应请求，返回响应的数据
浏览器解析响应内容，进行渲染，呈现给用户。
连接结束

http的状态码

1开头的像100 continue，表明目前为止都很正常，客户端可以继续发送请求
2开头的像200，表示请求已成功处理
3开头的是重定向状态码。301代表永久重定向，302代表临时重定向
4开头的是客户端错误状态码，400表示请求报文中存在错误，401表示该请求需要有认证信息，403表示请求被拒绝，404代表找不到页面
5开头的是服务器错误代码，500代表服务器执行请求错误，503代表无法处理请求

Http和Https的区别

Http是超文本传输协议，信息是明文传输，Https则是具有安全性的SSL/TLS加密传输协议
Http和Https用的端口不一样，Http的端口是80，而Https是443
Https协议需要向CA机构申请证书，一般需要一定的费用
Http是运行在TCP之上，而Https是运行在SSL/TLS之上，SSL/TLS运行在TCP协议之上

Https实现原理

HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密

客户端发起https请求，连接到服务端443端口
采用https协议服务端必须要有一套数字证书，可以是自己制作也可以是组织申请。

（区别就是自制的需要客户端的验证通过，而申请的不用。这套证书其实就是一对公钥和私钥，类似于锁头和钥匙，可以把锁头交给别人，别人可以用这个锁把重要的东西锁起来然后交给你。因为只有你有钥匙，所以保证了安全性）

服务端传送证书给客户端，这个证书就是公钥，还包含一些证书颁发机构的信息等。
客户端解析证书，这部分工作由TLS来完成，首先会验证证书是否有效，如果证书没问题就生成一个随机值，然后证书对该随机值加密。（就像上面所说的用锁头把信息锁起来，除非对方有钥匙不然打不开）
接着是客户端把这段加密了的随机值发送给服务端，服务端有私钥解开后，就跟把这段随机值当做是密钥，对腰发送的内容进行加密。这就是对称加密。客户端和服务端都知道这个密钥，所以只要密钥足够复杂就可以保证一定的安全性
最后服务端和客户端会互发信息查看是否都能接收到，若可以则连接建立完成。
整个过程即使第三方监听到了加锁的信息，因为没有密钥，所以也束手无策。

cookie

什么是cookie

http是无状态的，随着交互式web应用的兴起，必须记住哪些人登录了系统，把每个人操作分隔开
为了解决http无状态的情况，延续业务，就出现了cookie、session以及token
cookie由服务器生成，数据以k-v的形式存储在浏览器中，安全性低，像密码等就不能存在于这里

cookie的工作原理

浏览器第一次发送请求到服务端
服务器创建cookie，Cookie cookie=new Cookie(“key”，“value”)，然后放在response中响应给客户端
下一次浏览器再次访问服务端时就会携带服务器创建的cookie，服务器就通过request拿到cookie去区分不同的用户

在这里插入图片描述

session

什么是session

session就是给每个用户一个特定的sessionid（随机字符串）来识别用户
但是用户量一多对服务器来说是一笔巨大的开销，所以建议把sessionid集中在同一个地方存放
但是在分布式情境下可能会出现单点失败，负责session的机器挂了所有人就都得重新登录一遍，也不算友好。可以搞出集群，但是性能方面可能有负担
所以更好的解决方法是token

在这里插入图片描述

session的工作原理

浏览器端第一次发送请求到服务器端，服务器端创建一个Session存储信息，同时会创建一个Cookie来传送sessionid，然后将该Cookie发送至浏览器端
浏览器下次就会带上sessionid请求服务器，服务器就根据sessionid来提供信息

什么是token

这里总结的很笼统，具体可以看下B站这个视频，JWT详解
https://www.bilibili.com/video/BV1i54y1m7cP?share_source=copy_web

token是明文保存，类似于sessionid，用加密算法给数据（userid）加上一个签名，把这个签名和数据加在一块作为token，放在http头部中，下次访问时可以冲http头部获取
服务器不保存token，只负责生成和验证，用cpu计算的性能来获取存sessionid的空间。下次拿到token时对数据再做一次签名，然后与token里的签名进行比较，如果相同就可以是合法用户如果不相同就是被修改过或者未认证用户

在这里插入图片描述