TCP/IP协议栈:IP、TCP、UDP、HTTP协议

àì夳堔傛蜴生んèń 2024-04-01 18:53 178阅读 0赞

![c151e1c506826f9ebf0002c45a392293.jpeg][]

经过面试的同学经常会遇到这样的问题: 你是如何理解TCP/IP协议的？

回答：通讯协议？三次握手 ? 四次挥手？ 一脸懵逼！

如果你感觉已经被上述情景安排，那么有必要好好看看这篇文章。

另外附上一篇tcp/ip面试中的问题视频解答：面试中tcpip，哪些容易被问到的及解答

1 、什么是协议

协议实际上就是一种约定。好比说，我们做一个石头剪刀布的游戏，我们约定好：石头>剪刀、剪刀>布、布>石头，以此作为游戏规则。我们所有人都遵循这个约定，那么就不需要任何的多余的沟通便可以完成这个游戏。而这种方式形成的约定实际上就是一种协议了。

2、TCP/IP协议簇

话联网早期是，尽管知道计算机连接的原理，但是没有协议的时候，就没有办法进行大规模的通信使用。当时就衍生出了很多为了解决当时问题的协议，像TCP协议就是为了约定大家使用TCP连接时传输的一种协议，HTTP协议则是为了约定文本传输的一种协议。

而TCP/IP协议并不是指某一个具体的协议，它是指代一系列的协议栈，因此也叫TCP/IP协议栈或者TCP/IP协议簇。

所以广义上，我们说的TCP/IP指的是4层的总和。 而狭义上来说，指的是4层中的传输层和网络互联层。

在 TCP/IP协议簇 中，定义了包含对应 OSI 模型的每一层。但同时对 OSI 模型层做了简化处理。看看这种图理解一下：

TCP/IP层和OSI参考模型层的对应关系

也即是OSI模型中的7层，在TCP/IP中使用4层代替了。没办法，谁让OSI那么复杂呢。

在TCP/IP协议簇中每一层都有对应的协议，最终组成协议簇。

TCP/IP协议栈每一层的协议

我们经常说的TCP和UDP在协议栈的传输层，而IP协议则在协议栈的网络互联层。还有经常被问到的HTTP协议实际上在协议栈的应用层。

TCP/IP协议栈被分作这么多的层级，目的是为了整理硬件间通信时的一个通用的模型，因此它们每一层都和其上下层有关联性的，如下图：

TCP/IP协议栈数据封包分层

上面就是'TCP/IP协议'的总体概念了。但是其内部还有这么多的协议，这里挑几个常见的讲一讲，从底层到上层:

IP协议

TCP协议

UDP协议

HTTP协议

2. 1 IP协议

IP协议处于TCP/IP协议簇的网络互联层。它提供不可靠、无连接的服务，也即依赖其他层的协议进行差错控制。在局域网环境，IP协议往往被封装在以太网帧中传送。而所有的TCP、UDP、ICMP、IGMP数据都被封装在IP数据包包中传送。

在IP协议中，有两个重要的内容需要了解下。一是IP地址的概念，二是IP协议的报头。

2.1.1 IP地址的概念

其实对于IP地址我们日常接触还是挺多的。它给每一个接入互联网的计算器一个地址，从而使得其他的计算机能够访问到它。与此同时，当计算机有了地址之后，才能遵循IP协议，和其他的计算机进行数据的传递。

目前有两种IP版本，分别是IPV4和IPV6。IPV4占用8个字节32bit，而IPV6则是32个字节128bit。IPV6的可用的数量极其庞大，大到全球每一粒沙子都可以分配一个IPV6地址。

以IPV4为例, IPV4的32bit地址中,分为两个部分：网络号和主机号。同时根据不同的内容开头，又分为A、B、C、D、E类。

IPV4

网络号用于区分不同的网络点，比如一个公司是一个网络集群，我们可以通过他的网络号确定该公司网关，再通过主机号确定每一台计算。

假如一个C类的IP地址类型，包含了21位网络号，实际上就能区分出 2^21 个网络号，而在每一个网络号中，可以区分 2^8 -2 = 254（起始的网络号地址和最后一个为广播地址都不可用于主机）个主机号。如果一个网吧采用这种方式的话，那么他最多能安装254台机器。如果我们想要得到更多的主机号，应该延长主机号的位数，但是相应的，网络号的数量将减少，因为两者的总长度是不变的。

通过掩码能够改变网络号和主机号的位数。

通常，我们看到的掩码类似：

255.255.255.0

二进制表示：

11111111.11111111.11111111.00000000

如果一个IPV4地址为：192.168.1.12 那么IP地址和掩码经过与运算之后的结果为：192.168.1.0（192.168.001.000）, 这就是我们常说的网关！ 而从 192.168.1.1~192.168.1.254都可作为主机号。也即是这个网关下，可以容纳 254 台机器。

如果将掩码更改为：

255.255.254.0

二进制表示：

11111111.11111111.11111110.00000000

那么与运算的结果为：192.168.0.0 ，这时候可以使用的主机号就变成了 192.168.0.0 ~ 192.168.1.254, 即可容纳 510 台机器。

2.1.2 IP寻址

当一个 IP 包从一台计算机被发送，它会到达一个 IP 路由器。

IP 路由器负责将这个包路由至它的目的地，直接地或者通过其他的路由器。

在一个相同的通信中，一个包所经由的路径可能会和其他的包不同。而路由器负责根据通信量、网络中的错误或者其他参数来进行正确地寻址。

2.1.3 IP协议的报头

在上面的数据分层中，我们看到IP协议的构成实际上是 IP报头 + TCP协议内容。

因此决定一个IP协议属性的的关键是 IP报头的内容。 下面我们来看下IP协议的组成，IPV4中普通的IP首部长20个字节。其中有32位的源IP地址和32位的目的IP地址。

TTL：生存时间。代表了数据包可以经过的最多路由器数。比如TTL为10，意思是如果经过10次路由器转发，仍然未找到目的地址，则报文丢弃

8位协议指示的是传输层承载的协议

16位总长度：指IP数据包的最大长度。16bit那么最长可达65535字节。但是通过链路的MTU不会有这么大。因此如果数据包长度超过了MTU，数据包会被分片。如果发生了分片，则需要用到16位标识以及13位片偏移来找到分片的报文。

IP协议报头

2.2 TCP协议

2.2.1 TCP协议作用

TCP协议位于协议栈的传输层。当应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，TCP则把数据流分割成适当长度的报文段，最大传输段大小（MSS）通常受该计算机连接的网络的数据链路层的最大传送单元（MTU）限制。之后TCP把数据包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。

TCP为了保证报文传输的可靠，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。然后接收端实体对已成功收到的字节发回一个相应的确认(ACK)；如果发送端实体在合理的往返时延(RTT)内未收到确认，那么对应的数据（假设丢失了）将会被重传。

在数据正确性与合法性上，TCP用一个校验和函数来检验数据是否有错误，在发送和接收时都要计算校验和；同时可以使用md5认证对数据进行加密。

在保证可靠性上，采用超时重传和捎带确认机制。

在流量控制上，采用滑动窗口协议，协议中规定，对于窗口内未经确认的分组需要重传。

在拥塞控制上，采用广受好评的TCP拥塞控制算法（也称AIMD算法）。 该算法主要包括三个主要部分： （1）加性增、乘性减； （2）慢启动； （3）对超时事件做出反应。

2.2.2 TCP的报头

和IP协议一样，TCP协议也有他的报头部分。

以下即是图示：

TCP报头

源端口：发送方的端口号

目的端口：接受方的端口号

序号：发送方的序号

确认序号：接受方得到序号之后回复的确认序号

TCP 首部长度：4 bits，以32-bit字为单位。TCP首部长短，也是TCP报文数据部分的偏移量。范围5~15，即20 bytes ~ 60 bytes。可选项部分最多允许40 bytes。

标志位，标志位主要用户标志该报文当前的状态。

URG：指示报文中有紧急数据，应尽快传送（相当于高优先级的数据）。 ACK：确认序号（AN）有效。 PSH：接到后尽快交付给接收的应用进程。 RST：TCP连接中出现严重差错（如主机崩溃），必须释放连接，再重新建立连接。 SYN：处于TCP连接建立过程。 FIN：发送端已完成数据传输，请求释放连接。

2.2.2 TCP协议的连接时候的三次握手

TCP是一个面向连接的协议，在每一次传输数据前，客户端和服务端需要进行连接，这个链接就是着名的三次握手。

第一次：客户端向服务端发送一个 SYN（SEQ=x 客户端序号）报文给服务器端，进入SYN\_SEND状态。

第二次：服务器端收到SYN报文，回应一个SYN （SEQ=y 服务端序号）ACK(ACK=x+1 确认号=客户端序号+1）报文，进入SYN\_RECV状态。

第三次：客户端收到服务器端的SYN报文，回应一个ACK(ACK=y+1）报文，进入Established状态。

图解：

TCP的三次握手

思考：为什么要进行三次握手，而不是两次呢？ 比如在第一次握手之后，服务器进入准备状态，然后发送消息给客户端，客户端也进入准备状态，这就完成了双方的确认了。

回答：两次握手时，服务器提前进入准备状态之后，如果中途遇到网络中断，消息并没有传回给客户端，客户端将永远接不到服务器的给入状态，那么服务端将资源浪费在一个不存在的连接之上了。

思考2：三次握手就很安全了吗？

回答：在三次握手过程中，Server发送SYN-ACK之后，收到Client的ACK之前的TCP连接称为半连接（half-open connect），此时Server处于SYN\_RCVD状态，当收到ACK后，Server转入ESTABLISHED状态。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server回复确认包，并等待Client的确认，由于源地址是不存在的，因此，Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络堵塞甚至系统瘫痪。SYN攻击是一种典型的DDOS攻击，检测SYN攻击的方式非常简单，即当Server上有大量半连接状态且源IP地址是随机的，则可以断定遭到SYN攻击了，使用如下命令可以让之现行：

\#netstat -nap | grep SYN\_RECV

2.2.3 TCP协议的断开连接时候的四次挥手

既然TCP面向连接，那么肯定也有断开连接的操作。一个TCP完整的断开需要进行四次挥手。

第一次：客户端向服务端发送 FIN + ACK 报文，同时携带序号为 X。 客户端进入 FIN-WAIT1

第二次：服务器端回复 ACK 报文。附带序号Z和确认序号X+1，表示服务器已经接受到了客服端的报文。但是由于服务器可能还在处理事务，因此，报文并不会携带FIN标志。状态：CLOSE WAIT

第三次：在一段时间之后，服务器已经处理完毕，发送带有 FIN和ACK的报文，序号为Y，确认序号为 X + 1 。 状态： ACK-LAST

第四次：客户端发送ACK报文，序号为 X+1，确认号Y+1 。 客户端进入： TIME\_WAIT。服务端进图CLOSE（初始状态）

TCP四次挥手

思考：为什么建立连接是三次握手，而关闭连接却是四次挥手呢？

回答：这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

思考：为什么TIME\_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态？

原因有二：

一、保证TCP协议的全双工连接能够可靠关闭

二、保证这次连接的重复数据段从网络中消失

2.3 UDP协议

UDP协议全称是用户数据包协议，在网络中它与TCP协议一样用于处理数据包，两者同处于协议栈的传输层，和TCP不同的是，UDP是一种无连接的协议。

因为UDP是无连接的，所以相对来说，UDP的报头比TCP要简单多了。

UDP报头

UDP 特点 （1） UDP是一个非连接的协议，传输数据之前源端和终端不建立连接，当它想传送时就简单地去抓取来自应用程序的数据，并尽可能快地把它扔到网络上。在发送端，UDP传送数据的速度仅仅是受应用程序生成数据的速度、计算机的能力和传输带宽的限制；在接收端，UDP把每个消息段放在队列中，应用程序每次从队列中读一个消息段。 （2） 由于传输数据不建立连接，因此也就不需要维护连接状态，包括收发状态等，因此一台服务机可同时向多个客户机传输相同的消息。 （3） UDP信息包的标题很短，只有8个字节，相对于TCP的20个字节信息包的额外开销很小。 （4） 吞吐量不受拥挤控制算法的调节，只受应用软件生成数据的速率、传输带宽、源端和终端主机性能的限制。 （5）UDP使用尽最大努力交付，即不保证可靠交付，因此主机不需要维持复杂的链接状态表（这里面有许多参数）。 （6）UDP是面向报文的。发送方的UDP对应用程序交下来的报文，在添加首部后就向下交付给IP层。既不拆分，也不合并，而是保留这些报文的边界，因此，应用程序需要选择合适的报文大小。

我们经常使用“ping”命令来测试两台主机之间TCP/IP通信是否正常，其实“ping”命令的原理就是向对方主机发送UDP数据包，然后对方主机确认收到数据包，如果数据包是否到达的消息及时反馈回来，那么网络就是通的。

2.4 HTTP协议

HTTP协议名为超文本传输协议。这个协议在 TCP/IP 协议栈的应用层，因此我们无需操心HTTP是如何传输的，只需要关心，我们传输的内容，能否正确的被接收端识别。

HTTP 基于TCP实现，简单来说，TCP协议负责可靠的内容传输，HTTP协议负责识别内容，两者本身不在一个层面，没有可比性。

HTTP无状态的意思是，每一次的内容解析是没有关联的。TCP有状态是指两端在连接过程的。

HTTP包含两种报文类型：请求报文、响应报文。请求报文用在客户端对服务器的请求时使用的报文格式，响应用在服务器响应请求的报文格式。

2.4.1 HTTP协议请求消息结构

客户端发送一个HTTP请求到服务器的请求消息包括以下格式：请求行（request line）、请求头部（header）、空行和请求数据四个部分组成，下图给出了请求报文的一般格式。

HTTP请求消息体结构

HTTP消息体主要包含以下实质内容（空格和换行也必不可少）：

请求方法 URL：统一资源定位符 HTTP请求头部 HTTP请求体

以下是一个HTTP请求的例子：

HTTP请求实例

2.4.1.1 HTTP请求方法

HTTP包含了多种不同的请求方式，每一种请求方式用在不同的场景。

HTTP请求方法

2.4.1.2 URL —— 统一资源定位符

URL由三部分组成：资源类型、存放资源的主机域名、资源文件名。

URL的一般语法格式为：

(带方括号\[\]的为可选项)：

protocol :// hostname\[:port\] / path / \[;parameters\]\[?query\]\#fragment

protocol：https

hostname：baijiahao.baidu.com

parameters：id=1603848351636567407&wfr=spider&for=pc （使用&分割参数）

总结一下如下图：

附一张解析图

2.4.1.3 HTTP请求头

请求头中主要包含本次请求的附加信息，其中常用的字段如：

Accept： 指定客户端能够接收的内容类型

Accept-Encoding： 指定浏览器可以支持的web服务器返回内容压缩编码类型。

Accept-Language： 浏览器可接受的语言

Content-Length 请求的内容长度 如：Content-Length: 348

Content-Type 请求的与实体对应的MIME信息，常用的类型

Date 请求发送的日期和时间

更多的请求头字段参考 HTTP响应头和请求头信息对照表

2.4.1.4 HTTP请求体

在整个报文中，请求头之后，隔一行空格，以下部分就是HTTP的请求体了。 请求体是我们发送请求的时候需要传给接收端的内容。其格式需要和请求头中的Content-Type对应。不然会导致接受无法识别。

如上图中的请求题： name=tom&password=1234

2.4.2 HTTP响应

HTTP的响应同样分为：响应行、响应头、响应体。和请求报文有点类似。

总体结构如图：

HTTP响应报文

2.4.2.1 HTTP响应行

响应行中包含了HTTP的版本和本次请求的状态。请求状态的对应值见 HTTP响应码大全.

2.4.2.2 HTTP响应头

响应头用于描述服务器的基本信信息、数据的描述，这些信息将告知客户端如何处理响应题中的内容。

Allow 服务器支持哪些请求方法（如GET、POST等）。

Content-Encoding 文档的编码（Encode）方法。只有在解码之后才可以得到Content-Type头指定的内容类型。利用gzip压缩文档能够显着地减少HTML文档的下载时间。Java的GZIPOutputStream可以很方便地进行gzip压缩，但只有Unix上的Netscape和Windows上的IE 4、IE 5才支持它。因此，Servlet应该通过查看Accept-Encoding头（即request.getHeader('Accept-Encoding')）检查浏览器是否支持gzip，为支持gzip的浏览器返回经gzip压缩的HTML页面，为其他浏览器返回普通页面。

Content-Length 表示内容长度。只有当浏览器使用持久HTTP连接时才需要这个数据。如果你想要利用持久连接的优势，可以把输出文档写入 ByteArrayOutputStream，完成后查看其大小，然后把该值放入Content-Length头，最后通过byteArrayStream.writeTo(response.getOutputStream()发送内容。

Content-Type 表示后面的文档属于什么MIME类型。Servlet默认为text/plain，但通常需要显式地指定为text/html。由于经常要设置Content-Type，因此HttpServletResponse提供了一个专用的方法setContentType。

2.4.2.3 HTTP响应实体

响应实体中包含的就是客户端从服务器中获取的数据了。数据的格式和长度都会在响应体头中描述。

来源：[https://www.weidianyuedu.com][https_www.weidianyuedu.com]

[c151e1c506826f9ebf0002c45a392293.jpeg]: https://image.dandelioncloud.cn/pgy_files/images/2024/04/01/889290577ad44702ac1e80ff3330140b.jpeg
[https_www.weidianyuedu.com]: https://www.weidianyuedu.com