网络编程-从TCP连接的建立说起

前言

网络编程几乎是每一门编程语言都会涉及的内容,虽然各种语言调用的方式可能不一样,但它们背后的原理支持都是一样的。因此本文将从TCP的连接的建立说起。在此之前,假设你已经对计算机网络有了最基本的认识。

网络编程做什么

当下网络应用数不胜数,如微信,可以让你通过网络与远在异国他乡的朋友交流沟通;如在线视频,让你通过网络就可以观看你喜欢的视频,而这一切的背后,都有网络编程技术的支持。通俗来讲,可以认为网络编程是两台或者多台主机(应用)之间进行数据交换或传输

TCP:传输控制协议

而数据交换需要按照一定的规则,而这种规则就是协议。只有按照约定的规则,双方之间才能正确地进行数据交换。而TCP就是这些协议的一种,它提供一种面向连接的,可靠的字节流服务

  • 面向连接:两个使用TCP的应用在交换数据之前必须先建立一个TCP连接
  • 可靠的:TCP有很多机制来尽可能的保证数据不丢失
  • 字节流: 不区分是ASCII字符还是二进制数据,数据解释交给应用层

为什么要理解TCP

事实上不理解TCP背后的基本原理,仍然可以写出代码,但是当你遇到一些奇奇怪怪的而通过API的说明又无法解决的问题时,你就会庆幸自己花了点时间去学习TCP了。

TCP连接的建立

关于TCP连接的建立,你可能早已耳熟能详,其流程倒背如流。但我觉得还是有必要再理一理。TCP连接的建立,也就是三次握手的流程如下:

TCP三次握手

我们再试着描述一下三次握手的过程:

  • 服务端启动,并监听等待,处于LISTEN状态
  • 客户端发起连接请求,发送序列号seq=X,处于SYN_SENT状态
  • 服务端收到后,并回应ACK=X+1和seq=Y,处于SYN_RCVD状态,客户端发送能力,服务端接收能力正常。
  • 客户端收到服务端的ACK,连接建立,同时向服务端回复ACK,处于ESTABLISHED状态
  • 服务端收到ACK,连接建立,处于ESTABLISHED状态,客户端接收能力正常。

至此三次握手完成。需要注意的是,这是正常流程下的三次握手。而前面所说的这些状态可以通过netstat命令或者ss命令查看到,当然有些状态的存在时间比较短,可能无法观察到。

好了,那么问题来了:

  • 为什么要三次握手
  • 连接到一个不存在的端口会发生什么
  • 连接到一个不存在的服务器主机会发生什么
  • 初始seq是如何变化的
  • 半连接队列是什么
  • SYN攻击是什么

如果以上所有问题你都能轻而易举的回答出来,那么本文后面的内容你可以跳过了。

为什么要三次握手

这几乎是面试中必问的一个问题。一个TCP连接是全双工的,即数据在两个方向上能同时传输。因此,建立连接的过程也就必须确认双方的收发能力都是正常的。

四次握手是否可以呢?完全可以!但是没有必要!在服务端收到SYN之后,它可以先回ACK,再发送SYN,但是这两个信息可以一起发送出去,因此没有必要

两次握手是否可以呢?想象这样一种情况,客户端发起了一个连接请求在网络中滞留了很长时间,以至于在连接建立好且断开连接后,它才到达服务端,此时如果采用两次握手,那么服务端就会认为这个报文是新的连接请求,于是建立连接,等待客户端发送数据,但是实际上客户端根本没有发出建立请求,也不会理睬服务端,因此导致服务端空等而浪费资源。

为什么服务器会认为这个迟到的报文是新的连接请求?因为如果采用两次握手机制,那么服务端无法通过SYN来判断这是一个迟到或者重复的报文,还是正常到达的报文,但是对于三次握手,即便出现这样的情况,也不会在服务端建立起真正的连接。

一个正常的连接三次握手

我们利用tcpdump命令和nc命令来观察一个正常的tcp连接建立过程。首先在终端1准备抓包:

1
$ tcpdump port 1234 -i any -v -n

在终端2启动监听1234端口:

1
$ nc -l 1234

在终端3连接:

1
$ nc 127.0.0.1 1234

在终端1得到以下输出内容:

1
2
3
4
5
6
7
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
21:00:50.794424 IP (tos 0x0, ttl 64, id 50542, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.45848 > 127.0.0.1.1234: Flags [S], cksum 0xfe30 (incorrect -> 0x3163), seq 1310563628, win 43690, options [mss 65495,sackOK,TS val 3721786049 ecr 0,nop,wscale 7], length 0
21:00:50.794437 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.1234 > 127.0.0.1.45848: Flags [S.], cksum 0xfe30 (incorrect -> 0xef35), seq 1685196050, ack 1310563629, win 43690, options [mss 65495,sackOK,TS val 3721786049 ecr 3721786049,nop,wscale 7], length 0
21:00:50.794449 IP (tos 0x0, ttl 64, id 50543, offset 0, flags [DF], proto TCP (6), length 52)
127.0.0.1.45848 > 127.0.0.1.1234: Flags [.], cksum 0xfe28 (incorrect -> 0xc17a), ack 1, win 342, options [nop,nop,TS val 3721786049 ecr 3721786049], length 0

从上面抓包内容可以看到,总共有三个报文,分别是客户端发送到服务端的SYN,服务端回应给客户端的SYN和ACK,以及客户端回应给服务端的ACK。

连接到一个不存在的端口

如果要连接的服务器端口不存在会出现什么情况呢?我们利用nc命令来抓包观察。
在一个终端窗口使用管理员权限执行下面的命令进行抓包,并打印相关信息:

1
$ tcpdump port 1234 -i any -v -n

在另外一个终端使用nc命令尝试连接到本地的1234端口

1
2
$ nc 127.0.0.1 1234 -v
nc: connect to 127.0.0.1 port 1234 (tcp) failed: Connection refused

TCP抓包内容如下:

1
2
3
4
5
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
21:06:15.295407 IP (tos 0x0, ttl 64, id 29112, offset 0, flags [DF], proto TCP (6), length 60)
127.0.0.1.46108 > 127.0.0.1.1234: Flags [S], cksum 0xfe30 (incorrect -> 0x7fef), seq 1175796450, win 43690, options [mss 65495,sackOK,TS val 2076405654 ecr 0,nop,wscale 7], length 0
21:06:15.295462 IP (tos 0x0, ttl 64, id 58706, offset 0, flags [DF], proto TCP (6), length 40)
127.0.0.1.1234 > 127.0.0.1.46108: Flags [R.], cksum 0x77e7 (correct), seq 0, ack 1175796451, win 0, length 0

从抓包内容中可以看到,首先nc客户端发送一个SYN(Flags为S),seq为1175796450。而后收到一个RST(Flags为R),seq为1175796451。

也就是说,如果连接到一个不存在的端口,服务端所在的系统会响应一个RST(复位),直接终止连接。

Flags字段含义如下:

  • F : FIN - 结束; 结束会话
  • S : SYN - 同步; 表示开始会话请求
  • R : RST - 复位;中断一个连接
  • P : PUSH - 推送; 数据包立即发送
  • A : ACK - 应答
  • U : URG - 紧急
  • E : ECE - 显式拥塞提醒回应
  • W : CWR - 拥塞窗口减少

连接到一个不存在的服务器

同样是利用nc和tcpdump命令。

1
$ tcpdump port 1234 -i any -v -n

在另外一个窗口使用nc命令连接到一个不存在的或者无法连接的服务器地址:

1
2
$ nc 121.11.12.31 1234 -v
nc: connect to 121.11.12.31 port 1234 (tcp) failed: Connection timed out

tcpdump输出内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
21:13:04.259752 IP (tos 0x0, ttl 64, id 33411, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0xcdc0 (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75888078 ecr 0,nop,wscale 7], length 0
21:13:05.269438 IP (tos 0x0, ttl 64, id 33412, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0xc9ce (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75889088 ecr 0,nop,wscale 7], length 0
21:13:07.285415 IP (tos 0x0, ttl 64, id 33413, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0xc1ee (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75891104 ecr 0,nop,wscale 7], length 0
21:13:11.445491 IP (tos 0x0, ttl 64, id 33414, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0xb1ae (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75895264 ecr 0,nop,wscale 7], length 0
21:13:19.637403 IP (tos 0x0, ttl 64, id 33415, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0x91ae (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75903456 ecr 0,nop,wscale 7], length 0
21:13:35.765417 IP (tos 0x0, ttl 64, id 33416, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0x52ae (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75919584 ecr 0,nop,wscale 7], length 0
21:14:09.045497 IP (tos 0x0, ttl 64, id 33417, offset 0, flags [DF], proto TCP (6), length 60)
192.168.0.103.52402 > 121.11.12.31.1234: Flags [S], cksum 0xd0ad (correct), seq 2648987704, win 29200, options [mss 1460,sackOK,TS val 75952864 ecr 0,nop,wscale 7], length 0

通过实际操作可以发现,当发送第一个SYN没有响应时,客户端会再次发送;如果还是没有响应,再隔更长一段时间,继续发送SYN,最终连接超时。从观察情况来看,默认会进行5次重发,5次的重试时间间隔分别为1s, 2s, 4s, 8s, 16s。

初始序列号是如何变化的

通过前面的两次抓包可以看到,发送第一个SYN请求的初始序列号seq并不是固定的。实际上,不同的系统它的生成方法可能不同,但是可以知道的是,它在一定时间内,生成seq值肯定不同,否则服务端无法区分这到底是同一个seq的重发还是这个报文在网络中滞留一段时间后又重新到达。RFC 793指出初始序列号可以可看成一个32位的计数器,每隔4ms加1(但不同系统实际实现又可能不太一样,为了安全起见会处理成随机值),因此当它重新回到开始的时候,已经过了够长时间,使得网络中延迟的报文早已消失。

半连接队列

在服务器收到客户端的连接请求,并发送ACK之后,服务端处于SYN_RECV状态,此时的连接成为半连接,服务器会将半连接放到一个名为半连接队列的地方。

SYN攻击

正因如此,如果有人恶意地向服务器发送大量的SYN包,并且由于客户端IP是伪造的,导致服务器收不到ACK,不断重发ACK,以至于半连接队列容易占满,导致无法处理正常的连接请求,并且可能导致服务器资源耗尽。

如何处理SYN攻击又是另外一个话题。

总结

TCP三次握手的正常场景我们很容易描述出来,但是涉及更多细节以及异常场景的时候,我们可能不是那么熟悉,通过本文可以简单地了解TCP连接的建立,为后面的网络编程打下基础。但是需要说明的是,本文仅仅简单介绍了TCP连接的建立,并没有深入介绍。

守望 wechat
关注[编程珠玑]获取更多原创技术文章
出入相友,守望相助!