协议与接口
对于程式开发者而言,几乎每天都需要和协议和接口打交道,尽管有时候很少直接使用他们。开发一个应用程序,为了提高开发效率,往往会选择一个框架/库来进行开发,于是乎不可避免的就需要了解框架的API接口。协议往往是一些底层的通信规则,框架的最大职能就是实现和解析这些协议,并指定一套简洁的接口提供给开发者使用。
对于web编程,TCP,HTTP协议最熟悉不过了。TCP握手与挥手中,我们了解了TCP连接相关的具体状态细节。这些算是协议上的规定,对于程式而言,需要如何实现这些协议的从而提供接口呢?所幸,socket的为网络通信协议提供了编程接口。下面就来讨论tcp连接中的socket编程。
socket编程
socket就是不同计算机之间进行通信的一个抽象。socket是两个节点之间的数据传输,端点可能处于同一台主机,也可能位于不同的主机中,通常属于C/S架构,一个连接发起者(initiator)另外一个连接侦听者(listener),通常将从事侦听的socket称作“服务器”,将发起连接的套接字称作“客户端”。一图胜千言,下图几位常见的clinet-server通信模型:
tcplab.png上图中的左边是clinet,右边是server。server的生命周期大致如下:
- 创建socket。
- 绑定(bind)地址端口
- 监听网络连接
- 接受连接
- 关闭连接
clinet的生命周期则稍微简单点:
- 创建socket
- 绑定地址
- 发起连接
- 关闭连接
上述的过程使用python代码也非常简单:
clinet
import socket
address = ('127.0.0.1', 8000)
# 创建 tcp socket
client = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
# 发起连接
client.connect(address)
# 发送数据
client.send('hello-world')
# 接受数据
data = client.recv(1024)
print data
# 关闭连接
client.close()
服务端也很简单
import socket
address = ('127.0.0.1', 8000)
# 创建 tcp socket
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定地址
server.bind(address)
# 监听
server.listen(5)
while True:
# 获取连接
conn, addr = server.accept()
while True:
# 读取数据
data = conn.recv(1024)
# 发送数据给客户端
conn.sendall(data)
if not data:
# 关闭连接
conn.close()
break
# 关闭socket
server.close()
运行服务端server.py 服务端将会开启一个无限循环的监听,与客户端创建连接之后,进行数据交互,然后关闭连接,同时进入下一个生命周期的监听。
对于clinet的代码,发现我们并没有显示的绑定地址。对于服务器,绑定固定的端口,用于监听,客户端如果没有绑定,操作系统会自动分配绑定一个端口
socket与握手细节
从最上面的网络模型图看出,握手的连接发生在客户端connect,服务端的accept返回连接。握手的细节其实是客户端connet和服务端的listen过程,而accept只是返回队列里的连接。下面通过nc和wireshaker抓包来分析tcp三次握手和socket的通信细节。
clinet创建socket,server尚未bind地址
server如果尚未绑定地址,clinet就发起连接,将会收到一个RST拒绝连接的包。修改server.py运行
import socket
import time
address = ('127.0.0.1', 8000)
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
while True:
print 'sleep'
time.sleep(1)
clinet运行之后,connect调用之后触发了一个异常,程序退出。查看连接情况如下:
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
可见并没有创建连接通道,使用wireshaker的抓包如下:
1.png这个过程对于客户端是
- 客户端发送一个握手包(SYN Seq)
- 端口直接返回(RST, ACK)拒绝连接
server绑定地址
接下来把server的地址进行绑定,但是尚未监听。运行服务端
import socket
import time
address = ('127.0.0.1', 8000)
# 创建 tcp socket
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定地址
server.bind(address)
while True:
print 'sleep'
time.sleep(1)
使用nc查看连接情况
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 *.* CLOSED
然后运行clinet.py代码,这一次并不像之前connect调用就出现异常,而是客户端阻塞了一段时间之后,最后超时退出。查看wireshaker如下:
2.png- 客户端发送一个握手包(SYN Seq)
- 端口没有响应,导致客户端一直重发,此时connect阻塞,直到超时退出(退出进程)。
此时再使用netstat查看会得到如下结果:
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.55808 127.0.0.1.8000 SYN_SENT
tcp4 0 0 127.0.0.1.8000 *.* CLOSED
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.55808 127.0.0.1.8000 SYN_SENT
tcp4 0 0 127.0.0.1.8000 *.* CLOSED
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.55808 127.0.0.1.8000 SYN_SENT
tcp4 0 0 127.0.0.1.8000 *.* CLOSED
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 *.* CLOSED
通过wireshaker和netstat的观察,client发送SYN之后,自身状态编程SYS_SENT,server则一直处于CLOSED。这其实是第一次握手,clinet正等待server的ACK,可惜server并没有呼应,最后clinet超时退出。
server进行listen监听
将server.py加上监听调用,listen接口有一个参数,即连接队列中的连接数,通常设置为5,表示如果创建了连接,就存储再连接队列中,这个队列最大的容量是5。在mac上最大的则是128。
server.py
import socket
import time
address = ('127.0.0.1', 8000)
# 创建 tcp socket
server = socket.socket(family=socket.AF_INET, type=socket.SOCK_STREAM)
server.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# 绑定地址
server.bind(address)
# 监听
server.listen(5)
while True:
print 'sleep'
time.sleep(1)
查看连接状况:
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 *.* LISTEN
可见server处于LISTEM状态。
这次我们使用nc工具来进行交互实验:
☁ ~ nc 127.0.0.1 8000
上述命令等同于connect函数的调用,可见运行nc命令之后,客户端一直被阻塞。一段时间之后,再手动command+c 结束 nc 命令。此时再查看连接状态和抓包:
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 127.0.0.1.55832 ESTABLISHED
tcp4 0 0 127.0.0.1.55832 127.0.0.1.8000 ESTABLISHED
tcp4 0 0 127.0.0.1.8000 *.* LISTEN
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 127.0.0.1.55832 ESTABLISHED
tcp4 0 0 127.0.0.1.55832 127.0.0.1.8000 ESTABLISHED
tcp4 0 0 127.0.0.1.8000 *.* LISTEN
☁ ~ netstat -nat | grep -i "8000" | grep 127.0.0.1
tcp4 0 0 127.0.0.1.8000 127.0.0.1.55832 CLOSE_WAIT
tcp4 0 0 127.0.0.1.55832 127.0.0.1.8000 FIN_WAIT_2
tcp4 0 0 127.0.0.1.8000 *.*
3.png
从netstat和抓包的情况来看,此时client和server进行了三次握手:
- 客户端发送一个握手包(SYN Seq),第一次握手,客户端连接状态为 SYS_SEND
- 服务端端有响应,并发送一个(SYN, ACK)的应答包, 第二次握手 客户端的状态都变成ESTABLISHED表示可以发送数据了
- 客户端再向服务端发送(ACK)应答包,第三次握手,建立TCP连接,服务端也可以发送数据。
- 客户端发送一个[FIN, ACK]的包,表示关闭连接。
- 服务端发送一个[ACK]包表示确定关闭客户端到服务端的连接。客户端到服务端的连接断了。服务端到客户端的连接还保持。
listen&accept函数
通过上述的实验,可见tcp三次握手发生在client的connect调用之后,server端的listen函数调用之后,但是并不是由listen函数完成的,listen()的作用仅仅告诉内核一些信息,即连接队列的大小,三次握手是以后内核完成的。一旦完成了三次握手,内核就把连接放入连接队列之中。
当socket对象调用accpet函数的时候,就从连接队列中将tcp连接取出并返回。如果连接队列中没有连接,那么accept函数调用将会阻塞(如果socket是非阻塞模式,accept此时会返回,并触发一个异常)。
上述的代码listen只设置了5,如果连接同事超过了5个会怎么样呢?对于unix,server不会对再对建立新连接的握手进行应答,clinet的 connect 就会返回 ETIMEDOUT。可是在linux中server并不会拒绝连接,只是会延时连接,然后accept调用的时候却未必能把已经建立好的连接全部取出来。
总结
tcp握手的系统调用有 connect bind listen函数。python封装的api和C的很像。客户端connect发起握手,接受到服务器的ack应答返回。server在listen调用之后创建连接队列,同时监听端口,客户端connect发起的syn送达,在服务器的内核完成握手。只有当server端调用accept,才从连接队列中取tcp连接,如果连接队列中还没有握手后的连接,那么aceept调用在socket阻塞模式中就会阻塞,在非阻塞模式中则会返回异常错误。
网友评论