下图是网络通信中常见的架构，也就是CS架构。其中程序包括两部分，分别为客户端(Client)和服务端(Server)。当然，实际的环境还要复杂的多，在客户端和服务端之间可能有多种不同种类和数量的设备，这些设备都会增加网络通信的复杂性。自然，也会增加程序开发容错的复杂性。
图1 基本架构
TCP的基本流程
在分析异常情况之前，我们先回忆一下TCP协议的基本逻辑。在客户端和服务端能够收发数据之前首先必需建立连接。连接的建立在协议层面也是通过收发数据包完成，只不过在用户层面就是客户端调用了一个connect函数。连接的过程俗称“三次握手”，具体流程如图2所示。
图2 TCP的三次握手流程
TCP连接的断开也是比较复杂的，需要经过所谓的“四次挥手”的流程。其原因是因为TCP是双工通信，分别需要从客户端和服务端2侧断开连接。
图3 TCP的四次挥手
另外一个比较重要的内容是TCP协议的状态转换，理解了这个内容，我们才能清楚出现各种异常情况下数据包的内容。
图4 TCP状态转换图
本文只是简单回忆一下TCP的基本流程，详细的内容可以参考本号之前的文章《从TCP到Socket，彻底理解网络编程是怎么回事
异常情况分析
了解了TCP的基本流程之后，我们再看一下各种异常情况。这些异常情况才是我们在后续解决问题的时候的关键。了解了这些异常情况及原理，后面解决问题才能游刃有余。
1. 试图与一个不存在的端口建立连接(主机正常)
这里的不存在的端口是指在服务器端没有程序监听在该端口。我们的客户端就调用connect，试图与其建立连接。这时会发生什么呢？
这种情况下我们在客户端通常会收到如下异常内容：
[Errno 111] Connection refused(连接拒绝)
具体含义可以查一下Linux的相关手册，或者用搜索引擎搜索一下。试想一下，服务端本来就没有程序监听在这个接口，因此在服务端是无法完成连接的建立过程的。我们参考‘三次握手’的流程可以知道当客户端的SYNC包到达服务端时，TCP协议没有找到监听的套接字，就会向客户端发送一个错误的报文，告诉客户端产生了错误。而该错误报文就是一个包含RST的报文。这种异常情况也很容易模拟，我们只需要写一个小程序，连接服务器上没有监听的端口即可。如下是通过wireshark捕获的数据包，可以看到红色部分的RST报文。
图5 数据包截图
继续深入理解一下，在操作系统层面，TCP的服务端实际上就是从网卡的寄存器中读取数据，然后进行解析。对于TCP自然会解析出目的端口这个关键信息，然后根据这个信息查看有没有这样的套接字。这个套接字是什么呢？在用户层面是一个文件句柄，但在内核中实际是一个数据结构，里面记录了很多信息。这个数据结构存储在一个哈希表中，通过函数__inet_lookup_skb(net/inet_hashtables.h)可以实现对该数据结构的查找。对于上述情况，自然无法找到该套接字，因此TCP服务端会进行错误处理，处理的方式就是给客户端发送一个RST(通过函数tcp_v4_send_reset进行发送)。
2. 试图与一个某端口建立连接但该主机已经宕机(主机宕机)
这也是一种比较常见的情况，当某台服务器主机宕机了，而客户端并不知道，仍然尝试去与其建立连接。这种场景也是分为2种情况的，一种是刚刚宕机，另外一种是宕机了很长时间。为什么要分这2种情况？
这主要根ARP协议有关系，ARP会在本地缓存失效，TCP客户端就无法想目的服务端发送数据包了。
(192.168.1.100) 位于 08:00:27:1a:7a:0a [ether] 在 eth0
了解了上述情况，我们分析一下刚刚宕机的情况，此时客户端是可以向服务端发送数据包的。但是由于服务器宕机，因此不会给客户端发送任何回复。
图6 数据包截图
由于客户端并不知道服务端宕机，因此会重复发送SYNC数据包，如图6所示，可以看到客户端每隔几秒会向服务端发送一个SYNC数据包。这里面具体的时间是跟TCP协议相关的，具体时间不同的操作系统实现可能稍有不同。
3. 建立连接时，服务器应用被阻塞(或者僵死)
还有一种情况是在客户端建立连接的过程中服务端应用处于僵死状态，这种情况在实际中也会经常出现(我们假设仅仅应用程序僵死，而内核没有僵死)。此时会出现什么状态？TCP的三次是否可以完成？客户端是否可以收发数据？
在用户层面我们知道，服务端通过accept接口返回一个新的套接字，这时就可以和客户端进行数据往来了。也就是在用户层面来说，accept返回结果说明3次握手完成了，否则accept会被阻塞。在我们假设的情况下，其实就相当于应用程序无法进行accept操作了。
如果想彻底理解上面我们假设的问题，需要理解两点，一点是accept函数具体做了什么，另外一点是TCP三次握手的本质。
我们先试着理解第一点，accept会通过软中断陷入内核中，最终会调用tcp协议的inet_csk_accept函数，该函数会从队列中查找是否有处于ESTABLISHED状态的套接字。如果有则返回该套接字，否则阻塞当前进程。也就是说这里只是一个查询的过程，并不参与三次握手的任何逻辑。
三次握手的本质是什么呢？实际上就是客户端与服务端一个不断交流的过程，而这个交流过程就是通过3个数据包完成的。而这个数据包的发送和处理实际上都是在内核中完成的。对于TCP的服务端来说，当它收到SYNC数据包时，就会创建一个套接字的数据结构并给客户端回复ACK，再次收到客户端的ACK时会将套接字数据结构的状态转换为ESTABLISHED，并将其发送就绪队列中。而这整个过程跟应用程序没有半毛钱的关系。
当上面套接字加入就绪队列时，accept函数就被唤醒了，然后就可以获得新的套接字并返回。但我们回过头来看一下，在accept返回之前，其实三次握手已经完成，也就是连接已经建立了。
另外一个是如果accept没有返回，客户端是否可以发送数据？答案是可以的。因为数据的发送和接受都是在内核态进行的。客户端发送数据后，服务端的网卡会先接收，然后通过中断通知IP层，再上传到TCP层。TCP层根据目的端口和地址将数据存入关联的缓冲区。如果此时应用程序有读操作(例如read或recv)，那么数据会从内核态的缓冲区拷贝到用户态的缓存。否则，数据会一直在内核态的缓冲区中。总的来说，TCP的客户端是否可以发送数据与服务端程序是否工作没有任何关系。
当然，如果是整个机器都卡死了，那就是另外一种情况了。这种情况就我们之前分析的第2种情况一直了。因为，由于机器完全卡死，TCP服务端无法接受任何消息，自然也无法给客户端发送任何应答报文。
总结
今天我们主要介绍了连接建立过程中的各种异常情况，还有另外一种情况是在数据的传输过程中。比如传输过程中服务器突然掉电，或者程序crash等，后续我们将详细这些异常情况下在协议层的表现。
1. FastDFS适用的场景以及不适用的场景？FastDFS是为互联网应用量身定做的一套分布式文件存储系统，非常适合用来存储用户图片、视频、文档等文件。对于互联网应用，和其他分布式文件系统相比，优势非常明显。
FastDFS没有对文件做分块存储，因此不太适合分布式计算场景。
2. 当用fdfs_monitor /etc/fdfs/storage.conf 这个命令进行查看tracker与storage端是否建立连接时，两端始终显示都是offline。
解决：先查看tracker和storage的日志，确认服务是否有问题；如果日志显示正常，则有可能是在操作过程中，删除了tracker或storage某一方的缓存文件，导致缓存不匹配。此时，先关闭tracker和storage服务，
删除tracker.conf和storage.conf中指定的base_path目录下的data文件，再重启服务即可。
注意：如果删除了FastDHT 的base_path目录下的文件，切片集信息将全部丢失。
3. 在上传文件时，出现 ERROR - file: tracker_proto.c, line: 48, server: 101.200.215.232:23000, response status 28 != 0
解决：状态返回28，说明磁盘空间不足，注意FastDFS中有预留空间的概念，在tracker.conf中设置，配置项为：reserved_storage_space，缺省值为4GB，即预留4GB的空间。
请酌情设置reserved_storage_space这个参数，比如可以设置为磁盘总空间的20%左右可以修改/etc/fdfs/tracker.conf文件
4. 执行fdfs_test或fdfs_test1上传文件时，服务器返回错误号2
解决：状态返回2表示没有ACTIVE状态的storage server。可以执行fdfs_monitor查看服务器状态。
5. ERROR - file: /home/nginx/install/fastdfs-nginx-module/src/common.c, line: 561, logic file: M00/00/00/wKgBNU7wRbrcAYGuAALOPrGJ7YQ668.jpg not exists
解决： apache和nginx扩展模块版本v1.06及以上版本，需要在配置文件/etc/fdfs/fastdfs_mod.conf中设置storage server的存储路径信息。
一个示例如下所示：
store_path_count=1
store_path0=/home/yuqing/fastdfs
store_path_count和store_path #均需要正确设置，必须和storage.conf中的相应配置完全一致
6. nginx和apache扩展模块与FastDFS server版本对应关系
解决：扩展模块1.05： 针对FastDFs server v2.x，要求server版本大于等于v2.09
扩展模块1.07及以上版本： 针对FastDFs server v3.x
7. nginx扩展模块，不能正常显示图片的问题
解决：在配置文件/etc/fdfs/mod_fastdfs.conf中，缺省的设置是这样的：http.need_find_content_type=false这个参数在nginx中需要设置为true，apache中应该设置为false。
8. 分布式切图时，控制台为什么会提示“No buffer space available (maximum connections reached?):connect”？38error.png
解决：分布式切图过程中，向 FastDFS 存储上传切片时，占用的端口数增多，可能会达到本地操作系统的端口数的上限，所以出现上述问题。可通过如下方式规避：
Windows 系统
运行 “regedit.exe”，打开注册表，找到 “HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters”位置，添加“TcpTimedWaitDelay”，类型为DWORD，值为30；
添加“MaxUserPort”，类型为DWORD，值为20000（调大系统可用端口数）。
Linux 系统
运行 “vi /etc/sysctl.conf”，编辑文件，加入以下内容：
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_fin_timeout = 30
然后执行“/sbin/sysctl -p”让参数生效即可。
9. 在启动tracker的时候出现此类错误：ERROR - file: ../common/fdfs_http_shared.c, line: 128, param "http.mime_types_filename" not exist or is empty
解决：修改tracker.conf里面，把##include http.conf 改为#include http.conf ，再重启
10. 报错 ERROR - file: tracker_http_check.c, line: 132, http check alive, connect to http server 192.168.1.53:8888 fail, errno: 111, error info: Connection refused
解决：端口不对。要配置storage和nginx端口一致。
11. 报错400 badrequest [2011-12-12 15:24:21] ERROR - file: /tmp/fastdfs-nginx-module/src/common.c, line: 561, logic file: M00/00/00/wKgBNU7lqyjzJZ4mAA4CRXl5SCQ670.jpg not exists
2011/12/12 15:24:21 [error] 14147#0: *1 open() "/home/nginx/nginx/html/favicon.ico" failed (2: No such file or directory), client: 192.168.1.123, server: localhost, request: "GET /favicon.ico HTTP/1.1", host: "192.168.1.53:8090"
解决：修改/fastdfs/conf/mod_fastdfs.conf 里面url_have_group_name = true
12. 在tracker的日志里报出此类错误 ERROR - file: tracker_mem.c, line: 1406, the format of the file "/home/bstar/dfs_data/data/storage_sync_timestamp.dat" is invalid, group: group3, row count:1 >server count:0
解决：修改data里面的 storage_sync_timestamp.dat，把group3的信息删掉，然后重启tracker
13. 如何删除无效的storage server？
解决：可以使用fdfs_monitor来删除。命令行如下：
/usr/local/bin/fdfs_monitor delete
例如：/usr/local/bin/fdfs_monitor /etc/fdfs/client.conf delete group1 192.168.0.100
注意：如果被删除的storage server的状态是ACTIVE，也就是该storage server还在线上服务的情况下，是无法删除掉的
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）