为了账号安全,请及时绑定邮箱和手机立即绑定

TCP/IP协议栈 —— IP、TCP、UDP、HTTP协议详解

标签:
Java

经过面试的同学经常会遇到这样的问题: 你是如何理解TCP/IP协议的?
回答:通讯协议?三次握手 ? 四次挥手? 一脸懵逼!

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

1 、什么是协议

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

2、TCP/IP协议簇

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

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

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

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

webp

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


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

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

webp

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


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

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

webp

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类。

webp

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位片偏移来找到分片的报文。

webp

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协议也有他的报头部分。
以下即是图示:


webp

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状态。

图解:


webp

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(初始状态)

webp

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要简单多了。


webp

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)、空行和请求数据四个部分组成,下图给出了请求报文的一般格式。

webp

HTTP请求消息体结构

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

  • 请求方法

  • URL:统一资源定位符

  • HTTP请求头部

  • HTTP请求体

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


webp

HTTP请求实例

2.4.1.1  HTTP请求方法

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

webp

HTTP请求方法

2.4.1.2  URL —— 统一资源定位符

URL由三部分组成:资源类型、存放资源的主机域名、资源文件名。
URL的一般语法格式为:
(带方括号[]的为可选项):
protocol :// hostname[:port] / path / [;parameters][?query]#fragment
举个例子: https://baijiahao.baidu.com/s?id=1603848351636567407&wfr=spider&for=pc

protocol:https
hostname:baijiahao.baidu.com
parameters:id=1603848351636567407&wfr=spider&for=pc (使用&分割参数)

总结一下如下图:

webp

附一张解析图

2.4.1.3  HTTP请求头

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

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

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

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

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

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


    webp

    image.png

  • Date  请求发送的日期和时间
    更多的请求头字段参考 HTTP响应头和请求头信息对照表

2.4.1.4  HTTP请求体

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

2.4.2  HTTP响应

HTTP的响应同样分为:响应行、响应头、响应体。和请求报文有点类似。
总体结构如图:


webp

HTTP响应报文



作者:BennyLoo
链接:https://www.jianshu.com/p/dac7b8bdb682


点击查看更多内容
6人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消