标签归档：tcp

RSS feed of tcp

作者是 发布于 in Web开发.

最后更新于 .

经常在linux下工作的朋友一定经常需要用tcpdump抓包分析，不过有时候肉眼看起来实在是太累，不经意居然发现了这样一个好工具：
wireshark，下载页：http://www.wireshark.org/download.html

简单用他来演示一下tcp协议的整个过程：
先在开发机上开始抓包：

tcpdump -ieth1 host 172.27.193.234 -w tcpbao

调用一个发送tcp请求的小程序，可以抓到包---tcpbao.

用wireshark载入之后，会看到如下界面：

1

可见，整个过程完整的展现了TCP协议中，建立链接->发送数据->断掉链接的过程。
读者可以对照本博的：
TCP协议状态详解
或
http://bigwhite.blogbus.com/logs/11582229.html
来看。

简单说一下：

1~3个报文是tcp三次握手建立链接的过程
4~7个报文是客户端发送实体数据的过程
8~10个报文是客户端主动断掉链接的过程（这里和标准的关闭链接貌似有点出入，标准TCP协议貌似还要多返回一个ACK报文）

其实这个软件还支持直接抓包来查看报文的，详细可以看一下如下的在线文档，在此不再赘述。
http://man ...

作者是 发布于 in Web开发.

最后更新于 .

最近看《python核心编程》，书中实现了一个简单的1对1的TCPserver，但是在实际使用中1对1的形势明显是不行的，所以研究了一下如何在server端通过启动不同的线程（进程）来实现每个链接一个线程。

其实python在类的设计上已经考虑到了这一方面的需求，我们只要在自己的server上继承一下SocketServer.BaseRequestHandler就可以了。
server端代码如下：

#!/usr/bin/env python
import SocketServer
from time import ctime
HOST = ''
PORT = 21567
ADDR = (HOST, PORT)
class MyRequestHandler(SocketServer.BaseRequestHandler):
    def handle(self):
        print '...connected from:', self.client_address
        while True:
            self.request.sendall('[%s] %s' % (ctime(),self.request.recv(1024)))
tcpServ = SocketServer.ThreadingTCPServer(ADDR ...

作者是 发布于 in Web开发.

最后更新于 .

1、建立连接协议（三次握手）
（1）客户端发送一个带SYN标志的TCP报文到服务器。这是三次握手过程中的报文1。
（2） 服务器端回应客户端的，这是三次握手中的第2个报文，这个报文同时带ACK标志和SYN标志。因此它表示对刚才客户端SYN报文的回应；同时又标志SYN给客户端，询问客户端是否准备好进行数据通讯。
（3） 客户必须再次回应服务段一个ACK报文，这是报文段3。
2、连接终止协议（四次握手）
　 　由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
　（1） TCP客户端发送一个FIN，用来关闭客户到服务器的数据传送（报文段4）。
　（2） 服务器收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
　（3） 服务器关闭客户端的连接，发送一个FIN给客户端（报文段6）。
　（4） 客户段发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。

3、状态解释
CLOSED: 这个没什么好说的了，表示初始状态。
LISTEN: 这个也是非常容易理解的一个状态，表示服务器端的某个SOCKET处于监听状态，可以接受连接了 ...

作者是 发布于 in Web开发.

最后更新于 .

最近需要上线的逻辑server由于需要与大量的后台server交互，今天突然发现有大量的close_wait产生，于是仔细研究了一下：
首先我们知道，如果我们的服务器程序处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！
因为如果是CLIENT端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet：

Client ---> FIN  ---> Server
Client <--- ACK  <--- Server


这时候Client端处于FIN_WAIT_2状态；而Server 程序处于CLOSE_WAIT状态。

Client <--- FIN  <--- Server


这时Server 发送FIN给Client，Server 就置为LAST_ACK状态。

Client ---> ACK  ---> Server


Client回应了ACK，那么Server 的套接字才会真正置为CLOSED状态。

Server 程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Client，那么可能是在关闭连接之前还有许多数据要发送或者其他事要做，导致没有发这个FIN packet。
通常来说，一个CLOSE_WAIT会维持至少2个小时的时间（这个时间外网服务器通常会做调整，要不然太危险了）。如果有个流氓特地写了个程序，给你造成一堆的CLOSE_WAIT，消耗
你的资源，那么通常是等不到释放那一刻，系统就已经解决崩溃了 ...