TCP/IP协议理解
什么是TCP/IP模型?
TCP/IP模型是一系列网络协议的总称,这些协议的目的,就是使计算机之间可以进行信息交换。
所谓”协议”可以理解成机器之间交谈的语言,每一种协议都有自己的目的。TCP/IP模型一共包括几百种协议,对互联网上交换信息的各个方面都做了规定。
TCP存在之于”互联网“的意义有三点: - 让数据进行”可靠“,”高效“,”安全“的传输
TCP/IP模型的四层结构
这些协议可以大致分成四个层次,上一层的协议都以下一层的协议为基础。就像下面这张图:
从下到上的四层,分别为连接层(Link Layer)、网络层(Internet Layer)、传输层(Transport Layer)、应用层(Application Layer)。
可以这样理解它们的作用:
- 连接层负责建立电路连接,是整个网络的物理基础,典型的协议包括以太网、ADSL等等;
- 网络层负责分配地址和传送二进制数据,主要协议是IP协议;
- 传输层负责传送文本数据,主要协议是TCP协议;
- 应用层负责传送各种最终形态的数据,是直接与用户打交道的层,典型协议是HTTP、FTP等。
理解这个结构的关键,在于理解科学家在70年代设计互联网的原始目的,就是为了传输文本。所有协议最初都是为了这个目标而设计的,互联网架构的核心就是文本对话。
TCP报文格式
先了解一下TCP传输的报文格式,如图:
上图中有几个字段需要重点介绍下,两个序号和三个标志位:
- 序号:seq序号,占32位,用来标识从TCP源端向目的端发送的字节流,发起方发送数据时对此进行标记。
- 确认序号:ack序号,占32位,只有ACK标志位为1时,确认序号字段才有效,ack=seq+1。
- 标志位:共6个,即URG、ACK、PSH、RST、SYN、FIN等,具体含义如下:
- URG:紧急指针(urgent pointer)有效。
- ACK:确认序号有效标志位。
- PSH:接收方应该尽快将这个报文交给应用层。
- RST:重置连接。
- SYN:发起一个新连接。
- FIN:释放一个连接。
需要注意的是:
- 不要将确认序号ack与标志位中的ACK搞混了。
- 确认方ack=发起方req+1,两端配对。
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
establish 建立,创建
TCP3次握手
- 第一次握手:Client将标志位
SYN
置为1,随机产生
一个值seq=J
,并将该数据包发送给Server,Client进入SYN_SENT
状态,等待Server确认。 - 第二次握手:Server收到数据包后由标志位
SYN=1
知道Client请求建立连接,Server将标志位SYN
和ACK
都置为1,ack=J+1
,随机产生一个值seq=K
,并将该数据包发送给Client以确认连接请求,Server进入SYN_RCVD
状态。 - 第三次握手:Client收到确认后,检查
ack
是否为J+1,ACK
是否为1,如果正确则将标志位ACK
置为1,ack=K+1
,并将该数据包发送给Server,Server检查ack
是否为K+1
,ACK
是否为1,如果正确则连接建立成功,Client和Server进入ESTABLISHED
状态,完成三次握手,随后Client与Server之间可以开始传输数据了。
SYN攻击
在三次握手过程中,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
TCP序列号预测攻击(TCP_sequence_prediction_attack)
如何体现TCP的”高效、安全、可靠”
可以参考这篇文章:http://www.eepw.com.cn/article/201801/374917.htm
请注意:这里所说的”高效”只是相对TCP自己而言,因为这个”高效“会和后面我们会说到三次握手其中的第二步合并的握手相关,所以我在这里提一下,其实,UDP会因为没有了一些检测机制会比TCP更加高效,快速。
为什么不用两次握手或者四次握手等
这个就需要回到,TCP的一个”高效、安全、可靠”的上面来回答。
TCP作为一种可靠传输控制协议,其 核心思想: 既要保证数据可靠传输,又要提高传输的效率,而用三次恰恰可以满足以上两方面的需求!
TCP可靠传输的精髓:TCP连接的一方A,由操作系统动态随机选取一个32位长的序列号(Initial Sequence Number),假设A的初始序列号为1000,以该序列号为原点,对自己将要发送的每个字节的数据进行编号,1001,1002,1003…,并把自己的初始序列号ISN告诉B,让B有一个思想准备,什么样编号的数据是合法的,什么编号是非法的,比如编号900就是非法的,同时B还可以对A每一个编号的字节数据进行确认。如果A收到B确认编号为2001,则意味着字节编号为1001-2000,共1000个字节已经安全到达。
同理B也是类似的操作,假设B的初始序列号ISN为2000,以该序列号为原点,对自己将要发送的每个字节的数据进行编号,2001,2002,2003…,并把自己的初始序列号ISN告诉A,以便A可以确认B发送的每一个字节。如果B收到A确认编号为4001,则意味着字节编号为2001-4000,共2000个字节已经安全到达。
一句话概括,TCP连接握手,握的是啥?
通信双方数据原点的序列号!
以此核心思想我们来分析二、三、四次握手的过程。
A <——-> B
四次握手的过程:
1.1 A 发送同步信号SYN + A’s Initial sequence number
1.2 B 确认收到A的同步信号,并记录 A’s ISN 到本地,命名 B’s ACK sequence number
1.3 B发送同步信号SYN + B’s Initial sequence number
1.4 A确认收到B的同步信号,并记录 B’s ISN 到本地,命名 A’s ACK sequence number
很显然1.2和1.3 这两个步骤可以合并,只需要三次握手,可以提高连接的速度与效率。
二次握手的过程:
2.1 A 发送同步信号SYN + A’s Initial sequence number
2.2 B发送同步信号SYN + B’s Initial sequence number + B’s ACK sequence number
这里有一个问题,A与B就A的初始序列号达成了一致,这里是1000。但是B无法知道A是否已经接收到自己的同步信号,如果这个同步信号丢失了,A和B就B的初始序列号将无法达成一致。
于是TCP的设计者将SYN这个同步标志位SYN设计成占用一个字节的编号(FIN标志位也是),既然是一个字节的数据,按照TCP对有数据的TCP segment 必须确认的原则,所以在这里A必须给B一个确认,以确认A已经接收到B的同步信号。
有童鞋会说,如果A发给B的确认丢了,该如何?
A会超时重传这个ACK吗?不会!TCP不会为没有数据的ACK超时重传。
那该如何是好?B如果没有收到A的ACK,会超时重传自己的SYN同步信号,一直到收到A的ACK为止。
补充阅读:
第一个包,即A发给B的SYN 中途被丢,没有到达B
A会周期性超时重传,直到收到B的确认
第二个包,即B发给A的SYN +ACK 中途被丢,没有到达A
B会周期性超时重传,直到收到A的确认
第三个包,即A发给B的ACK 中途被丢,没有到达B
A发完ACK,单方面认为TCP为 Established状态,而B显然认为TCP为Active状态:
a. 假定此时双方都没有数据发送,B会周期性超时重传,直到收到A的确认,收到之后B的TCP 连接也为 Established状态,双向可以发包。
b. 假定此时A有数据发送,B收到A的 Data + ACK,自然会切换为established 状态,并接受A的 Data。
c. 假定B有数据发送,数据发送不了,会一直周期性超时重传SYN + ACK,直到收到A的确认才可以发送数据。
TCP4次挥手
由于TCP连接时全双工的,因此,每个方向都必须要单独进行关闭,这一原则是当一方完成数据发送任务后,发送一个FIN
来终止这一方向的连接,
收到一个FIN
只是意味着这一方向上没有数据流动了,即不会再收到数据了,但是在这个TCP连接上仍然能够发送数据,直到这一方向也发送了FIN
。
首先进行关闭的一方将执行主动关闭,而另一方则执行被动关闭,上图描述的即是如此。
- 第一次挥手:Client发送一个FIN,用来关闭Client到Server的数据传送,Client进入FIN_WAIT_1状态。
- 第二次挥手:Server收到FIN后,发送一个ACK给Client,确认序号为收到序号+1(与SYN相同,一个FIN占用一个序号),Server进入CLOSE_WAIT状态。
- 第三次挥手:Server发送一个FIN,用来关闭Server到Client的数据传送,Server进入LAST_ACK状态。
- 第四次挥手:Client收到FIN后,Client进入TIME_WAIT状态,接着发送一个ACK给Server,确认序号为收到序号+1,Server进入CLOSED状态,完成四次挥手。
为什么客户端最后还要等待2MSL?
MSL(Maximum Segment Lifetime),TCP允许不同的实现可以设置不同的MSL值。
第一,保证客户端发送的最后一个ACK报文能够到达服务器,因为这个ACK报文可能丢失,站在服务器的角度看来,我已经发送了FIN+ACK报文请求断开了,客户端还没有给我回应,应该是我发送的请求断开报文它没有收到,于是服务器又会重新发送一次,而客户端就能在这个2MSL时间段内收到这个重传的报文,接着给出回应报文,并且会重启2MSL计时器。
第二,防止类似与“三次握手”中提到了的“已经失效的连接请求报文段”出现在本连接中。客户端发送完最后一个确认报文后,在这个2MSL时间中,就可以使本连接持续的时间内所产生的所有报文段都从网络中消失。这样新的连接中不会出现旧连接的请求报文。
为什么建立连接是三次握手,关闭连接确是四次挥手呢?
建立连接的时候, 服务器在LISTEN状态下,收到建立连接请求的SYN报文后,把ACK和SYN放在一个报文里发送给客户端。
而关闭连接时,服务器收到对方的FIN报文时,仅仅表示对方不再发送数据了但是还能接收数据,而自己也未必全部数据都发送给对方了,所以己方可以立即关闭,也可以发送一些数据给对方后,再发送FIN报文给对方来表示同意现在关闭连接,因此,己方ACK和FIN一般都会分开发送,从而导致多了一次。
如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75分钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
参考文档
[1] TCP的三次握手与四次挥手(详解+动图) https://blog.csdn.net/qzcsu/article/details/72861891
[2] https://betterexplained.com/articles/a-simple-introduction-to-computer-networking/
[3] https://www.cnblogs.com/laowz/p/6947539.html
[4] https://www.cnblogs.com/imyalost/p/6086808.html
[5] https://www.cnblogs.com/phpstudy2015-6/p/6801886.html
[6] https://www.cnblogs.com/Robin-YB/p/6668762.html
[7] https://www.zhihu.com/question/24853633/answer/115173386