关于网络基础知识一些问题

·_int

已于 2022-08-06 12:08:43 修改

阅读量529

点赞数

分类专栏：学习小结文章标签：网络 tcp/ip 网络协议

于 2022-08-04 17:05:53 首次发布

本文链接：https://blog.csdn.net/m0_51529857/article/details/126068212

版权

学习小结专栏收录该内容

28 篇文章 0 订阅

订阅专栏

文章目录

一、OSI七层模型和TCP/IP四层模型
- 概念
- 功能
2、 TCP和UDP有什么区别？
UDP和TCP对应的场景应用是什么？
3、什么是TCP三次握手机制？
4、关于TCP三次握手的一些问题
5、四次挥手的一些问题
6、HTTP的相关问题

一、OSI七层模型和TCP/IP四层模型

在这里插入图片描述

概念

OSI七层模型：OSI七层模型的全称为开放式系统互联通信参考模型， OSI七层模型分别为：应用层、表示层、、会话层、运输层、网络层、数据链路层、物理层。
TCP/IP四层模型：是由实际应用发展总结出来的。基于TCP/IP的参考模型将协议分成四个层次，分别为应用层、传输层、网络层和物理链路层。也会将物理链路层分为物理层和数据链路层，这样TCPIP模型就变成了五层一般我们使用的四层模型。

功能

· 应用层：为应用程序提供交互服务。在互联网中应用层协议有很多，比如域名系统DNS，支撑万维网应用的HTTP，支撑电子邮件的SMTP等。
· 表示层：主要负责数据格式的转换，如加密解密、转换翻译、压缩解压等。
· 会话层：负责在网络中的两节点之间建立联系，维持和终止通信，如服务器验证用户是否登录就是有会话层完成的。
· 运输层：也可以叫传输层，向主机进程提供通用的数据传输服务。主要应用的两种协议：
TCP协议：提供面向链接，稳定的数据传输服务。
UDP协议：提供无连接的，尽最大努力的数据传输服务，但不保证数据传输的可靠性。
· 网络层：选择合适的路由和交换节点，确保数据的即使传送。主要包括IP协议。
· 数据链路层：将网络层传下来的IP数据包组装成帧，并在相邻节点的链路上传送帧。
· 物理层：实现相邻节点比特流的透明传输，尽可能的屏蔽传输介质和通信手段带来的差异。

2、 TCP和UDP有什么区别？

	UDP	TCP
是否链接	无连接	面向链接
是否可靠	不可靠传输	可靠传输
是否有序	无序	有序
传输速度	快	慢
链接对象个数	支持一对一，一对多，多对多	只能一对一
传输方式	面向报文	面向字节流
首部开销	首部开销小，仅为8字节	首部最小20字节，最大60字节
适用场景	适用实时应用（直播，视频电话）	使用要求可靠性传输的应用（文件传输）

总结：TCP应用于传输层有必要实现可靠传输的场景，UDP用于高校传输和实时性要求较高的场景。TCP和UDP应该根据应用的需求来使用。

UDP和TCP对应的场景应用是什么？

应用层协议	应用	传输层协议
STMP	电子邮件	TCP
TELNET	远端终端接入	TCP
HTTP/HTTPS	万维网	TCP
FTP	文件传输	TCP
DNS	域名转换	UDP·12
TFTP	文件传输	UDP
SNMP	网络管理	UDP
NFS	远端文件服务器	UDP

3、什么是TCP三次握手机制？

在这里插入图片描述
第一次握手：客户端请求建立连接，向服务端发送一个同步报文（SYN=1），同时随机选择一个数seq = x作为初始序列号，并进入SYN_SENT状态，等待服务器确认。
第二次握手：服务器收到请求报文后，如果同意建立链接，就会向客户端发送一个同步确认报文（SYN=1，ACK=1）确认号ack = x+1，同时选择一个随机数seq=y作为初始序列号，此时服务器进入SYN_RECV状态。
第三次握手：客户端收到服务器的确认之后，向服务器发送确认报文（ACK=1），确认号ack = y+1，序列号为seq=x+1，客户端和服务器都进入ESTABLISHED状态，完成三次握手。

ps：在理想状态下，TCP链接一旦建立，在通信双方中任意一方关闭连接之前，TCP链接都会一直保持下去。

4、关于TCP三次握手的一些问题

为什么需要三次握手，而不是两次？

1、防止过期的请求报文突然传送到服务器，因而产生资源的浪费。
当A发送请求报文1给B时，由于网络问题导致B收不到A的请求报文1，所以B不会返回确认报文给A；A长时间没有收到B的确认报文就会再次发送请求报文2，这次请求报文2顺利到B，经过握手之手A和B都进入ESTABLISHED状态并完成数据的传输，然后断开链接；此时，请求报文1才刚刚到达B，B就会发送确认报文，但是此时A已经是CLOSED状态无法接收B的确认报文，这将会使得B进入长时间的状态，造成资源的浪费。
2、三次握手才能让双方都确认对方的发送和接收能力都正常。
第一次握手：客户端只是发送请求报文，什么都不能确认；服务器可以确认自己的接收能力和对方的发送能力正常。
第二次握手：客户端可以确认自己发送、接受能力正常，对方的发送和接受能力正常。
第三次握手：服务器可以确认自己发送能力正常，对方的接受能力正常。

所以三次握手才能让双方确认自己和对方的发送和接收能力都是正常的。

3、告诉对方的初始序列号，并确认收到对方的初始序列号。
TCP实现了可靠的数据传输，原因之一就是TCP报文段中维护了序号字段和确认序列号字段，通过这两个字段都可以知到自己发出的数据那些是被对方接收了。这两个字段的值会在序列号值的基础递增，如果是两次握手，只有发起方的序列号才可以确认，而另一方的额初始序列号得不到确认。

为什么时三次握手，而不是四次？

因为三次握手已经可以确认双方的发送和接受能力，双方都知道彼此已经准备好了了，而且也可以完成对双方初始序列号的确认，也就不需要四次握手。

三次握手阶段，最后一次ACK包丢失，会发生什么？

服务端：
1、第三次握手的ACK在网络中丢失，那么服务端就会处于SYN_RECV状态，根据TCP的超时重传机制，等待之后就会发送SYN+ACK包，以便客户端重新发送ACK包。
2、如果重发指定次数之后，仍然没有收到客户端的ACK应答，那么一段时间后服务端就会主动关闭这个连接。

客户端：
客户端认为这个连接已经建立，如果客户端向服务端发送数据，服务端将以RST包（Reset，标示复位，用于异常的关闭连接）响应。此时，客户端知道第三次握手失败。

5、四次挥手的一些问题

四次挥手的过程

在这里插入图片描述
第一次挥手：客户端向服务端发送释放报文（FIN=1 ， ACK=1），主动关闭连接，同时等待服务端确认。序列号seq = u（客户端上次发生的报文的最后一个字节的序号+1）；确认号ack=k（服务端上次发送的报文的最后一个字节的序号+1）。
第二次挥手：服务端收到连接释放报文后，立即发出确认报文（（ACK=1），序列号seq=k，确认号ack = u+1。这时TCP连接处于半关闭状态（客户端到服务端连接已经释放，但是服务端到客户端的连接还未释放）。这表示客户端已经没有数据发送了，但是客户端可能还要给客户端发送数据。
第三次挥手：服务端向客户端发送的连接释放报文（FIN=1，ACK=1），主动关闭连接，同时等待客户端确认。序列号seq = w（服务端上次发送的报文的最后一个字节序号+1）；确认号ack=u+1，和第二次挥手相同，因为客户端已经没有发送过数据。
第四次握手：客户端收到服务端的连接释放报文后，立即发出确认报文（ACK=1），序列号seq = u+1，确认号ack = w+1。此时，客户端进入TIME-WAIT状态。此时客户端到TCP连接还未释放，必须经过2*MSL（最长报文段寿命）的时间后，才会进入CLOSED状态。而服务端只要收到客户端发出的确认，就会进入CLOSED状态。所以服务端结束TCP连接的时间比客户端早一些。

为什连接时三次握手，关闭的时候确实四次挥手？

服务端在收到客户端的FIN报文段，可能还需要一些数据传输，所以不能马上关闭连接，但是会做出应答，返回ACK报文段。接下来可能会继续发送数据，在数据发送完后，服务器会客户端发送FIN报文，表示数据已经发送完了，请求关闭连接。服务器的ACK和FIN一般都会分开发送，从而导致多了一次，所以一共需要四次挥手。

为什么客户端的TIME-WAIT状态必须等待2MSL？

1、确保ACK报文能够到达服务端，从而使服务端正常关闭连接。
第四次挥手时，客户端第四次挥手的ACK报文不一定会到达服务端，服务端就会超时重传ACK/FIN报文，如果此时客户端断开连接就不能响应服务端的二次请求，这样服务端迟迟收不到FIN/ACK报文的确认，就不会断开连接。如果服务端重发的FIN没有成功的在2MSL时间里传给客户端，服务端就会继续超时重试直到断开连接。
2、防止已经失效的连接请求报文段出现在之后的连接中。
TCP要求在2MSL内不使用相同的序列号。客户端在发送最后一个ACK报文后，在经过时间2MSL，就可以保证本链接持续的时间内产生的所以报文段都从网络中消失。这样就可以使下一个连接中不会出现这种旧的连接请求报文段。

TCP协议是如何保障可靠性的？

TCP主要提供检验和、确认应答、超时重传、滑动窗口、拥塞控制和流量控制等方法实现可靠性传输。
1、检验和：通过检验和的方式，接收端可以检测出来的数据是否有差错和异常，假如有差错就会直接丢弃TCP段，重新发送。
2、确认应答：序列号的作用不仅仅是应答的作用，有了序列号能够将接受的数据根据序列号排序，并且去掉重复序列号的数据。
TCP传输过程中，每次接收方收到数据后，都会对传输方进行确认应答。也就是ACK报文，这个ACK报文当中带有对应的确认序列号，告诉发送方接收到了哪些数据，下一次数据从哪里出发。
3、滑动窗口：滑动窗口既提高了报文传输的效率，也避免了发送方发送过多的数据而导致接收方无法正常处理异常。
4、超时重传：超时重传是指发送出去的数据包到确认包之间的时间，如果超过了这个时间就会被认为丢包了，需要重传。最大超时重传时间是动态计算的。
5、拥塞控制：在数据传输过程中，可能由于网络状态的问题，造成网络拥堵，此时引入拥塞控制机制，在保证TCP可靠性的同时，提高性能。
6、流量控制：如果主机A向主机B发送数据，不考虑主机B的性能，则可能导致主机B的接受缓冲区满了无法在接收数据，从而导致大量数据包丢失，引发重传机制，进而大大降低传输效率。引入了流量控制机制，主机B通过告诉主机A自己缓冲区的大小，来使主机A控制发送的数据量。

6、HTTP的相关问题

HTTP常见的状态码

状态码	状态特征
200	服务器已经成功处理请求
301	（永久移动）请求网页已经永久移动到新位置。此时服务器返回此响应时会自动请求跳转到新位置
302	（临时移动）服务器目前从不同位置的网页响应请求，但请求者继续使用原有位置来进行后续请求
400	客户端请求语法有错，不能被服务器识别
403	服务器收到请求但是拒绝提供服务
404	找不到服务器请求的网页
500	服务器内部错误，无法完成请求

GET方法和POST方法的区别：

url的可见性：get方法可见。post方法不可见。
数据传输上：get方法通过拼接url进行传递参数。post方法通过请求体传递参数。
缓存性：get方法可以请求缓存。post方法不能请求缓存。
点击后退或者刷新的反应：get方法没有什么其他影响。post方法数据会被重新提交，
传输数据的大小：get方法一般不超过2k-4k。post方法请求传输数据的大小根据php.ini 配置文件设定，也可以无限大。
对数据类型的限制：get方法只允许ASCII码。post方法没有限制，也允许二进制数据。
安全性：与post方法相比get方法的安全性较差，因为发送的数据是url的一部分，所以在传输敏感信息或者密码时不使用get方法。post较为安全，因为参数不会被保存在浏览器历史或者web日志中。
数据包：GET产生一个TCP数据包；POST产生两个TCP数据包。对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200（返回数据）；而对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok（返回数据）。在网络环境好的情况下，发一次包的时间和发两次包的时间差别基本可以无视。而在网络环境差的情况下，两次包的TCP在验证数据包完整性上，有非常大的优点。并不是所有浏览器都会在POST中发送两次包，Firefox就只发送一次。

HTTP的长连接和短连接

在HTTP1.0中默认使用的是短链接。也就是说，浏览器和服务器每进行一次HTTP操作，就建立一次连接，但任务已结束就中断连接。如果客户端浏览器访问的某个HTML或其他类型的Web页中包含有其他的Web资源，比如JS文件，图像文件，CSS文件等；当浏览器没遇到这样一个Web资源就会建立一个HTTP会话。但从HTTP1.1起，默认使用长连接，用以保持连接特性。使用长连接HTTP协议，会在响应头有加入这行代码：Connection：keep-alive。在使用长连接的情况下，当一个网页完成后，客户端和服务器之间用于传输HTTP数据的TCP连接不会关闭，如果客户端再次访问这个网页，会继续使用这一条已经建立的连接。Keep-Alive不会永久保持，他有一个保持时间，可以在不同的服务器软件中设定这个时间。实现长连接和服务端都支持长连接。
HTTP协议的长连接和短链接，实质上是TCP协议的长连接和短链接。

HTTP1.0和HTTP1.1的区别

1、长连接：HTTP1.1支持长连接和请求的流水线处理，在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟，在HTTP1.1中默认开启Connection：keep-alive，一定程度弥补了HTTP1.0每次都要创建连接的缺点。
2、缓存处理：在HTTP1.0中主要使用header里的If-Modified-Since,Expires来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略例如Entity tag，If-Unmodified-Since, If-Match, If-None-Match等更多可供选择的缓存头来控制缓存策略。
3、Host头处理：HTTP1.1在Request消息头里头多了一个Host域，而且是必传的，HTTP1.0则没有这个域。
4、带宽优化：HTTP/1.0中，存在一些浪费带宽的现象，例如客户端只是需要某个对象的一部分，而服务器却将整个对象送过来了。又比如下载大文件时不支持断点续传功能，在发生断连后不得不重新下载完整的包。
HTTP/1.1中在请求消息中引入了range头域，它支持只请求资源的某个部分。在响应消息中Content-Range头域声明了返回的这部分对象的偏移值和长度。如果服务器相应地返回了对象所请求范围的内容，则响应码为206（Partial Content），它可以防止Cache将响应误以为是完整的一个对象。

HTTP和HTTPS的区别

	HTTP	HTTPS
端口	80	443
安全性	无加密，安全性较差	有加密机制，安全性较高
资源消耗	较少	由于加密机制，消耗资源较多
是否需要安全证书	不需要	需要
协议	运行在TCP协议之上	运行在SSL协议之上，SSL运行在TCP协议之上

HTTPS的优缺点

优点：
1、安全性：
· 使用HTTPS协议认可用户和服务器，确保数据发送到正确的客户机和服务器。
· HTTPS协议是由SSL+HTTP协议构成的可进行加密传输，身份认证的网络协议，要比HTTP协议安全，可防止数据在传输过程中不被窃取，改变，确保数据的完整性。
· HTTPS是现行构架下最安全的解决方案，虽然不是最安全的方法，但是大幅增加了中间人攻击的成本。

缺点：
1、在相同网络环境中，HTTPS相比HTTP无论是响应时间还是耗电量都有大幅上升。
2、HTTPS的安全是有范围的，在黑客攻击，服务器劫持等情况下几乎起不到作用。
3、在现有的证书及之下，中间人攻击依然有可能发生。
4、HTTPS需要更多的服务器资源，也会导致成本的升高。

HTTPS的原理

在这里插入图片描述
加密流程按图中的序列号分为：
1、客户端请求HTTPS网址，然后连接到server的443端口。
2、采用HTTPS协议的服务器必须有一套CA证书。颁发证书的同时会产生一个公钥和私钥。私钥由服务端自己保存，不可以泄露，公钥则是附带在证书的信息中，可以公开的。证书本身也附带一个证书电子签名，这个签名用来验证证书的完整性和真实性，可以防止证书被篡改。
3、服务端响应客户端请求，将证书传递给客户端，证书包含公钥和大量其他信息，比如证书颁发机构信息，公司信息和证书效期等。
4、客户端解析证书并对其进行验证。如果证书不是可信机构颁布的，或者整数中域名与其实际域名不一样或者证书已经过期的，就会向访问者显示一个警告，由其选择是否继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥A。然后客户端还会生成一个随机码Key，并使用公钥A将对其加密。
5、客户端把加密后的随机码Key发送给服务器，作为后面对称加密的密钥。
6、服务器在收到随机码Key之后使用私钥B将其解密。经过以上这些步骤，客户端和服务器终于建立了安全连接，完美的解决了对称加密加密的密钥泄露问题，接下来就可以用对称加密愉快的进行通信了。
7、服务器使用密钥（随机码Key）对数据进行对称加密并发送给客户端，客户端使用相同的密钥（随机码Key）解密数据。
8、双方使用对称加密愉快的传输数据。

在浏览器中输入www.baidu.com 后执行的全部过程

1、域名解析，将域名变为ip地址。浏览器搜索自己的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的DNS缓存（维护一张域名与IP的对应表）；若没有，则搜索操作系统的hosts文件（维护一张域名与开发的对应表）。若都没有，则找tcp/ip参数中设置首选的DNS服务器，就是本地DNS服务器（递归查询），本地域名服务器查询自己的DNS缓存，如果没有，则迭代查询。将本地DNS服务器将IP地址返回给操作系统，同时缓存IP。
2、发起tcp三次握手，简历tcp连接，浏览器会以一个随机端口向服务端的web程序80端口发起tcp连接。
3、tcp连接建立后发起http请求，
4、服务器响应http请求，客户端可到html代码。服务端web应用收到http请求后，就开始处理请求，处理后返回给浏览器html文件。
5、浏览器解析html代码，并请求html文件。
6、浏览器对页面进行渲染，并呈现给用户。
在这里插入图片描述

什么是Cookie和Session？

Cookie ：
Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，他会在浏览器下次请求同一服务器再发起请求被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一个浏览器，如保持用户的登陆状态。Cookie使基于无状态的HTTP协议记录稳定的状态信息成为可能。
Cookie主要作用一下方面：
1、会话状态管理（如用户登录状态，购物车，游戏分数等需要记录的数据）
2、个性化设置（用户自定义设置，主题等）
3、浏览器行为跟踪（如跟踪分析用户行为等）
Session：
Session代表着服务器和客户端一次会话的过程。Session对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的Web页之间跳转时，储存在Session对象中变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者Session超时失效时会话结束。

Cookie和 Session是如何配合的呢？

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的Session，请求返回时将此Session的唯一标识信息SessionID返回给浏览器，浏览器接收到服务器返回的SessionID信息后，会把此消息储存到Cookie之中，同时Cookie记录此SessionID属于哪个域名。
当用户第二次访问服务器的时候，请求会自动判断这个域名是否在Cookie信息中，如果存在自动将Cookie信息也发送给服务端，服务端会从Cookie中获取SessionID，再根据SessionID查找相应的Session信息，如果没找到就说明用户没有登录或者登录失效，如果找到了Session证明用户已经登录就可以执行后续操作。

Cookie和Session的区别

1、作用范围不同：Cookie储存在客户端（浏览器），Session储存在服务端。
2、获取方式不同：Cookie只能保存ASCII，Session可以储存任意数据类型。
3、有效期不同：Cookie可设置为长时间保持，比如我们经常使用的默认登录功能，Session一般失效时间较短，客户端关闭或者Session超时都会失效。
4、隐私策略不同：Cookie储存在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码储存在Cookie中会导致信息窃取；Session储存在服务端，安全性相对于Cookie要好一点。
5、储存大小不同：单个Cookie保存数据不会超过4kb，Session可储存的数据远高于Cookie。

分布式Session问题

1、客户端储存：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些步敏感的信息。
2、Session复制：任何一个服务器上的Session发生改变（增删查），该节点会把这个Session的所有内容序列化，然后广播给其他节点。
3、共享Session：将用户的Session等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。
4、Nginx ip_hash策略：服务器使用Nginx代理，某个请求按访问IP的hash分配，这样来自同一个IP固定访问一个后台服务器，避免了在服务器A创建Session，第二次分发到服务器B的现象。