linux下网络编程常见问题

网络程序异常退出无core文件产生

这种情况发生在一边连接端已经关闭,但是另外一边还在对连接句柄做send操作,这样做send操作的进程会收到SIGPIPE信号,默认行为是直接退出且不会产生core。为了避免退出,一般在启动的时候加上 signal(SIGPIPE, SIG_IGN) 来忽略这种错误。

 

发送端send成功,但是接收端却recv失败

send只是表示数据copy到了发送缓冲区,并不代表数据到达了recv,若这时候网络出问题,对面确实收不到数据。

 

如何让接受方知道发送方每次发送的数据有多长

两种方式

1. 和ip协议类似在每段发送的数据前拼接一个固定长度的包头,包头里存储数据长度类型等信息,接受方那边recv2次,第一次收包头,第二次根据包头里的长度申请空间收数据

2. 和http包头类似,已特殊标记符号为结尾,http是2个\r\n

 

服务端地址重用问题

服务端重启会被告知端口被占用,这是因为服务端主动调用了close操作。主动断开连接方的端口会在断开以后短时间处于TIME_WAIT状态,这时候端口不能被重用,解决办法是在setsockopt函数里面设置SO_REUSEADDR来保证地址的重用。

    

为什么会出现TIME_WAIT

 四次挥手过程中,主动断开方收到对面的fin包以后要反发一个ack包回复(这是第四次挥手),发完ack以后要等待2个TIME_WAIT(60S)时间才关闭自己,原因是因为ack包会出现丢包的情况,如果出现,对面由于没收到ack可能又会重发fin包,而ack—>fin这一来一回的最长时间正好是2个TIME_WAIT时间,所以主动断开方在等待2个TIME_WAIT时间以后没收到fin就说明ack包已经正常到底对面连接

 

CLOSE_WAIT状态出现在什么时候

被动关闭方收到对面的fin包以后到发送自己的fin包这段时间网络会处于 CLOSE_WAIT状态,不过这段时间比较短,除非是自己这边网络异常不能关闭连接。

 

listen的backlog设置

listen里面维护2个队列,一个是已经连接完成的队列,这个长度为backlog,一个是未完成连接的队列,这个长度为backlog/2,accept取的是已完成队列里的句柄,如果accept取的不及时可能导致队列满,这样listen就会拒绝连接

 

你可能感兴趣的:(linux)