当前位置：首页 > news >正文

计算机网络-网络协议

news 文章来源：https://blog.csdn.net/qq_45901741/article/details/135081156 2024/11/19 10:40:28

一、TCP/IP协议

作为一个小萌新，当然我无法将tcp/ip协议的大部分江山和盘托出，但是其中很多面试可能问到的知识，我觉得有必要总结一下！
首先，在学习tcp/ip协议之前，我们必须搞明白什么是tcp/ip协议。

1、什么是tcp/ip协议

书本上的定义：网络协议是为计算机网络中进行数据交换而建立的规则、标准或约定的集合。

比如：中国人之间交流使用汉语，要遵循汉语的语法结构和发音；那如果我们跟英国人交流的话，就要使用英语的语法结构和发音；人与人之间交流所用的语言就是一种协议。对于计算机来说，两台机器之间的通信就要制定各种各样的协议，例如：文件传输使用TCP协议，域名系统使用DNS协议。数据根据协议规定的内容进行传输，这样就实现了两台机器之间的通信。

总的来说：网络协议就是人为规定的一套通信规范，只要双方都遵循这个规范，就能实现交流。
TCP/IP具体含义：从字面意义上讲，可能会认为 TCP/IP 是指 TCP 和 IP 两种协议。然而多数情况下，它只是利用ip进行通信时所必须用到的协议群的统称。具体来说，IP 或 ICMP、TCP 或 UDP、TELNET 或 FTP、以及 HTTP 等都属于 TCP/IP 协议。他们与 TCP 或 IP 的关系紧密，是互联网必不可少的组成部分。TCP/IP 一词泛指这些协议，因此，有时也称 TCP/IP 为网际协议群。

2、tcp/ip协议的分层

TCP/IP协议族中有一个重要的概念是分层，提到协议分层，通常会联想到OSI的七层协议经典架构，但是TCP/IP协议族的结构则稍有不同，但是二者之间有一定联系，如图所示：
在这里插入图片描述

tcp/ip协议分为“应用层、传输层、网络层、数据链路层”。

2.1、应用层

顾名思义，应用层就是我们应用和接触最多的层，我们最常写的Java程序，甚至QQ微信都是应用层的产物。
应用层决定这次通信的应用类型，比如说FTP、DNS、SMTP等等，同时HTTP协议也属于应用层的范围。通俗来讲，应用层决定这一次通信要干嘛。

2.2、传输层

应用层把数据丢给传输层后，传输层把数据进行一下包装，包装纸上面写着“源端口、目的端口、序号、确认序号、检验和等TCP自身的数据，
传输层提供两台计算机之间的数据传输，传输层中包含着两个很吊的协议，分别是TCP和UDP协议，而且没有第三种协议可走。
TCP和UDP协议的区别

1、基于连接（TCP）与无连接(UDP)。 2、TCP要求系统资源较多，UDP较少。 3、UDP程序结构较简单。
4、流模式（TCP）与数据报模式(UDP)。 5、TCP保证数据正确性，UDP可能丢包。 6、TCP保证数据顺序，UDP不保证。
7、TCP面向连接（如打电话要先拨号建立连接）;UDP是无连接的，即发送数据之前不需要建立连接。
8、TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。
9、TCP面向字节流，实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的，没有拥塞控制，因此网络出现拥塞不会使源主机的发送速率降低（对实时应用很有用，如IP电话，实时视频会议等）。
10、每一条TCP连接只能是点到点的;UDP支持一对一，一对多，多对一和多对多的交互通信。
11、TCP首部开销20字节;UDP的首部开销小，只有8个字节。 12、TCP的逻辑通信信道是全双工的可靠信道，UDP则是不可靠信道。

此外，面试中经常提及的三次握手，四次挥手就是TCP协议的部分内容。

三次握手，四次挥手
TCP有6种标志符

	1、SYN(synchronous),建立联机2、ACK(acknowledgement),确认3、PSH(push),传输4、FIN(finish),结束5、RST(reset),重置6、URG(urgent),紧急

1、三次握手：

概念：指在发送数据的准备阶段，服务器和客户端之间需要三次交互

第一次握手：建立连接时，客户端向服务器发送一个SYN包，并进入SYN_SENT状态，等待服务器确认

第二次握手：当服务器收到客户端的请求后，此时要给客户端给一个确认信息ACK,同时发送SYN包，此时服务器进入 SYN_RECV状态

第三次握手：客户端收到服务器发的ACK+SYN包后，向服务器发送ACK,发送完毕之后，客户端和服务器进入
ESTABLISHED(TCP连接成功)状态，完成三次握手

在这里插入图片描述

2、四次挥手
概念：所谓四次挥手就是说关闭TCP连接的过程，当断开一个TCP连接时，需要客户端和服务器共发送四个包确认

第一次挥手：客户端发送一个FIN,用来关闭客户端到服务器的数据传输，客户端进入FIN_WAIT_1状态

第二次挥手：服务器收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号），服务器进入CLOSE_WAIT状态

第三次挥手：服务器发送一个FIN,用来关闭服务器到客户端的数据传输，服务器进入LAST_ACK状态

第四次挥手：客户端收到FIN后，客户端进入TIME_WAIT状态，接着发送一个AKC给服务器，确认序号为收到序号+1，服务器进入CLOSED状态，完成四次挥手

TCP四次挥手过程中通信双方状态解析：

FIN_WAIT_1: 其实FIN_WAIT_1和FIN_WAIT_2状态的真正含义都是表示等待对方的FIN报文。而这两种状态的区别是：

FIN_WAIT_1状态：实际上是当SOCKET在ESTABLISHED状态时，它想主动关闭连接，向对方发送了FIN报文，此时该SOCKET即进入到FIN_WAIT_1状态。而当对方回应ACK报文后，则进入到FIN_WAIT_2状态，当然在实际的正常情况下，无论对方何种情况下，都应该马上回应ACK报文，所以FIN_WAIT_1状态一般是比较难见到的，而FIN_WAIT_2状态还有时常常可以用netstat看到。（主动方）
FIN_WAIT_2：实际上FIN_WAIT_2状态下的SOCKET，表示半连接，也即有一方要求close连接，但另外还告诉对方，我暂时还有点数据需要传送给你(ACK信息)，稍后再关闭连接。（主动方）

CLOSE_WAIT:表示在等待关闭。当对方close一个SOCKET后发送FIN报文给自己，你系统毫无疑问地会回应一个ACK报文给对方，此时则进入到CLOSE_WAIT状态。接下来呢，实际上你真正需要考虑的事情是察看你是否还有数据发送给对方，如果没有的话，那么你也就可以 close这个SOCKET，发送FIN报文给对方，也即关闭连接。所以你在CLOSE_WAIT状态下，需要完成的事情是等待你去关闭连接。（被动方）

LAST_ACK: 被动关闭一方在发送FIN报文后，最后等待对方的ACK报文。当收到ACK报文后，也即可以进入到CLOSED可用状态了。（被动方）

TIME_WAIT: 表示收到了对方的FIN报文，并发送出了ACK报文，就等2MSL后即可回到CLOSED可用状态了。如果FIN WAIT1状态下，收到了对方同时带FIN标志和ACK标志的报文时，可以直接进入到TIME_WAIT状态，而无须经过FIN_WAIT_2状态。（主动方）

CLOSED: 表示连接中断。

为什么要有TIME_WAIT这个状态？

假设最终的ACK丢失，主机2将重发FIN，主机1必须维护TCP状态信息以便可以重发最终的ACK，否则会发送RST，结果主机2认为发生错误。TCP实现必须可靠地终止连接的两个方向(全双工关闭)，主机1必须进入 TIME_WAIT 状态，因为主机1可能面临重发最终ACK的情形。

出现太多TIME_WAIT可能导致的后果：

在高并发短连接的TCP服务器上，当服务器处理完请求后立刻按照主动正常关闭连接。这个场景下，会出现大量socket处于TIMEWAIT状态。如果客户端的并发量持续很高，此时部分客户端就会显示连接不上。我来解释下这个场景。主动正常关闭TCP连接，都会出现TIMEWAIT。为什么我们要关注这个高并发短连接呢？有两个方面需要注意：

① 高并发可以让服务器在短时间范围内同时占用大量端口，而端口有个0~65535的范围，并不是很多，刨除系统和其他服务要用的，剩下的就更少了。

②在这个场景中，短连接表示“业务处理+传输数据的时间远远小于 TIMEWAIT超时的时间”的连接。这里有个相对长短的概念，比如，取一个web页面，1秒钟的http短连接处理完业务，在关闭连接之后，这个业务用过的端口会停留在TIMEWAIT状态几分钟，而这几分钟，其他HTTP请求来临的时候是无法占用此端口的。单用这个业务计算服务器的利用率会发现，服务器干正经事的时间和端口（资源）被挂着无法被使用的时间的比例是 1：几百，服务器资源严重浪费。

说个题外话，从这个意义出发来考虑服务器性能调优的话，长连接业务的服务就不需要考虑TIMEWAIT状态。同时，假如你对服务器业务场景非常熟悉，你会发现，在实际业务场景中，一般长连接对应的业务的并发量并不会很高

综合这两个方面，持续的到达一定量的高并发短连接，会使服务器因端口资源不足而拒绝为一部分客户服务。

time_wait状态如何避免

首先服务器可以设置SO_REUSEADDR套接字选项来通知内核，如果端口忙，但TCP连接位于TIME_WAIT状态时可以重用端口。在一个非常有用的场景就是，如果你的服务器程序停止后想立即重启，而新的套接字依旧希望使用同一端口，此时SO_REUSEADDR选项就可以避免TIME_WAIT状态。

2.3、网络层

应用层将数据丢给传输层进行包装，网络层则是用来处理这些流动的数据包，也就是如果把相应的数据包路由到指定的地点，为通信时的网络传输选择传输路线。
就像送快递一样，需要选择正确路线，才能送到你家。

2.4、数据链路层

数据链路层包含了软件与硬件的接口部分，以及各种网络设备的硬件，也就是整个网络通信过程中最底层的基础设施。

一个HTTP请求的响应过程：

简单了解了每一层的作用之后，我们试着串起来，摸索一下一次整体的http请求到响应的过程。
拿访问google做个例子：

0.访问google.com，按下回车。

1.应用层准备好请求报文，通过DNS服务进行域名解析，得到google的ip地址，并将报文发到传输层。

2.传输层收到报文后，会将请求的数据包进行拆分，打包，并对每个包裹打上tag。在请求报文的基础上，加上一层TCP的首部信息，然后发往网络层。

3.到了网络层以后，IP协议就发挥了巨大的作用，IP协议中需要两个比较重要的信息，那就是ip地址和mac地址。ip已经在应用层通过dns解析出来了，那mac怎么办。。。真尴尬，然而这时ARP协议又冒了出来，它可以根据ip地址反向查询到目标主机的mac地址。好了，现在啥都有了，打包带走，把数据发到数据链路层。

4.终于走到基础设施这里了，此时数据包就在一根根光纤中旋转跳跃的奔向目的地，当然，整个过程不一定是直达的，可能需要经过各种中转站，就跟坐火车转车一样的。

5.请求到达服务器后，先从数据链路层往上走，并验证消去以太网首部信息，在网络层消去IP首部，在传输层消去TCP首部，就像剥洋葱一样一层一层去皮，最后剩下的就请求报文。在应用层对请求做出处理之后，需要对请求返回一个响应。而整个响应的传输过程就和请求一样，一层一层的封装，响应到达客户端时再一层一层的消去首部，最后呈现响应的结果。

简而言之，他们可以概括为一张这样的图：
在这里插入图片描述

二、HTTP/HTTPS协议

在了解这两个之前，我们先来看两张图：
在这里插入图片描述

从这两张图片来看，http协议和https协议有一个最显而易见的区别：https比http要安全。

1、基本概念

1.1、http

HTTP：是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（基于TCP/IP协议），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。

HTTP 是一个属于应用层的面向对象的协议，HTTP 协议一共有五大特点：
1、支持客户/服务器模式；
2、简单快速；
3、灵活；
4、无连接；
5、无状态。

其中我们主要了解一下无连接和无状态这两个特点：

1、无连接
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。采用这种方式可以节省传输时间。

早期这么做的原因是 HTTP 协议产生于互联网，因此服务器需要处理同时面向全世界数十万、上百万客户端的网页访问，但每个客户端（即浏览器）与服务器之间交换数据的间歇性较大（即传输具有突发性、瞬时性），并且网页浏览的联想性、发散性导致两次传送的数据关联性很低，大部分通道实际上会很空闲、无端占用资源。

因此 HTTP 的设计者有意利用这种特点将协议设计为请求时建连接、请求完释放连接，以尽快将资源释放出来服务其他客户端。

但是，随着时间的推移，网页变得越来越复杂，里面可能嵌入了很多图片，这时候每次访问图片都需要建立一次 TCP 连接就显得很低效。后来，Keep-Alive 被提出用来解决这效率低的问题。

Keep-Alive 功能使客户端到服务器端的连接持续有效，当出现对服务器的后继请求时，Keep-Alive
功能避免了建立或者重新建立连接。市场上的大部分 Web 服务器，包括 iPlanet、IIS 和 Apache，都支持 HTTP
Keep-Alive。对于提供静态内容的网站来说，这个功能通常很有用。但是，对于负担较重的网站来说，这里存在另外一个问题：虽然为客户保留打开的连接有一定的好处，但它同样影响了性能，因为在处理暂停期间，本来可以释放的资源仍旧被占用。当Web服务器和应用服务器在同一台机器上运行时，Keep-Alive
功能对资源利用的影响尤其突出。

这样一来，客户端和服务器之间的 HTTP 连接就会被保持，不会断开（超过 Keep-Alive
规定的时间，意外断电等情况除外），当客户端发送另外一个请求时，就使用这条已经建立的连接。

2、无状态
无状态是指协议对于事务处理没有记忆能力，服务器不知道客户端是什么状态。

即我们给服务器发送 HTTP 请求之后，服务器根据请求，会给我们发送数据过来，但是，发送完，不会记录任何信息。

HTTP 是一个无状态协议，这意味着每个请求都是独立的，Keep-Alive 没能改变这个结果。

缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大。另一方面，在服务器不需要先前信息时它的应答就较快。

HTTP 协议这种特性有优点也有缺点：

1、优点在于解放了服务器，每一次请求“点到为止”不会造成不必要连接占用
2、缺点在于每次请求会传输大量重复的内容信息。

客户端与服务器进行动态交互的 Web 应用程序出现之后，HTTP 无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品。

于是，两种用于保持 HTTP 连接状态的技术就应运而生了，一个是 Cookie，而另一个则是 Session。

3、Cookie和 Session：

1、Cookie：
Cookie可以保持登录信息到用户下次与服务器的会话，换句话说，下次访问同一网站时，用户会发现不必输入用户名和密码就已经登录了（当然，不排除用户手工删除Cookie）。而还有一些Cookie在用户退出会话的时候就被删除了，这样可以有效保护个人隐私。

Cookies 最典型的应用是判定注册用户是否已经登录网站，用户可能会得到提示，是否在下一次进入此网站时保留用户信息以便简化登录手续，这些都是 Cookies 的功用。
另一个重要应用场合是“购物车”之类处理。用户可能会在一段时间内在同一家网站的不同页面中选择不同的商品，这些信息都会写入 Cookies，以便在最后付款时提取信息。

2、 Session：

它是通过服务器来保持状态的。

当客户端访问服务器时，服务器根据需求设置 Session，将会话信息保存在服务器上，同时将标示 Session 的 SessionId 传递给客户端浏览器，浏览器将这个 SessionId 保存在内存中，我们称之为无过期时间的 Cookie。浏览器关闭后，这个 Cookie 就会被清掉，它不会存在于用户的 Cookie 临时文件。

以后浏览器每次请求都会额外加上这个参数值，服务器会根据这个 SessionId，就能取得客户端的数据信息。

如果客户端浏览器意外关闭，服务器保存的 Session 数据不是立即释放，此时数据还会存在，只要我们知道那个 SessionId，就可以继续通过请求获得此 Session 的信息，因为此时后台的 Session 还存在，当然我们可以设置一个 Session 超时时间，一旦超过规定时间没有客户端请求时，服务器就会清除对应 SessionId 的 Session 信息。

1.2、https

HTTPS：是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。

那么https协议是怎么用SSL加密的呢？
其实SSL也是一种协议，SSL/TLS 在 TCP 之上加了一层加密等处理，不影响原有的 TCP 和 HTTP，上下都是透明的，用来实现安全传输。
其过程如图所示：
在这里插入图片描述

SSL/TLS 概述

1、主要功能：

防冒充(pretending): 验证交互双方（通常只是对服务端）身份的真实性；防窃听(eavesdropping):
对传输的数据进行加密，即使被截获也无法被识别；防篡改(tampering):
确保接收方收到的数据是原始未篡改过的，若被篡改能识别出来并丢弃；

2、SSL/TLS 交互过程（加密过程）：
这里有个重要依据是RSA公钥加密算法：

对于数据交换双方，都拥有自身的公钥和私钥，私钥都为自己私藏，公钥都向对方公开；
同样一个数据，发送方使用自身的私钥加密，接收方收到后可以用发送方的公钥解密。

在连接的时候，会有以下操作：

服务端：向客户端发送服务端证书(证书中包含服务端公钥)，并向客户端索要客户端证书；
客户端：收到服务端证书后，验证其身份有效性(可信机构颁发、域名一致、未过期等)，如验证失败则握手失败，如成功则从中取出服务端公钥；
客户端：向服务端发送客户端证书(证书中包含客户端公钥)；
服务端：收到客户端证书后，验证其身份真实性，如验证失败则握手失败。

2、http和https的区别

由上图我们可以知道，http和https最显而易见的区别，就是一个安全一个不安全。

那么为什么他们会有这样的区别呢？
答：HTTP协议传输的数据都是未加密的，也就是明文的，因此使用HTTP协议传输隐私
信息非常不安全，为了保证这些隐私数据能加密传输，于是网景公司设计SSL（Secure 
Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而就诞生了HTTPS。简
单来说，HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协
议，要比http协议安全。

HTTPS和HTTP的区别主要如下：

1、https协议需要到ca申请证书，一般免费证书较少，因而需要一定费用。

2、http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。

3、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

4、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

3、https的优缺点

3.1、https协议的优点

其实，HTTPS也并非绝对安全。掌握根证书的机构、掌握加密算法的组织同样可以进行中间人形式的攻击，但HTTPS仍是现行架构下最安全的解决方案，主要有以下几个好处：

（1）使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；

（2）HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。

（3）HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。

（4）谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。

3.2、https的缺点

虽然说HTTPS有很大的优势，但其相对来说，还是存在不足之处的：

（1）HTTPS协议握手阶段比较费时，会使页面的加载时间延长近50%，增加10%到20%的耗电；

（2）HTTPS连接缓存不如HTTP高效，会增加数据开销和功耗，甚至已有的安全措施也会因此而受到影响；

（3）SSL证书需要钱，功能越强大的证书费用越高，个人网站、小网站没有必要一般不会用。

（4）SSL证书通常需要绑定IP，不能在同一IP上绑定多个域名，IPv4资源不可能支撑这个消耗。

（5）HTTPS协议的加密范围也比较有限，在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用。最关键的，SSL证书的信用链体系并不安全，特别是在某些国家可以控制CA根证书的情况下，中间人攻击一样可行。