[置顶] 网络编程杂项 (持续更新)

By [email protected]


——记录一些小问题,陷阱


1. 调用bind时,如果地址是0(就是INADDR_ANY那个宏),就绑定本地所有IP,如果端口是0,就随机选择一个可用的端口(想要知道具体端口,可以调用getsockname查看)

2. send recv 与 read write 的区别主要在于:send 和 recv 可以设置一些 flag,而 read 和 write 则没有

3. 阻塞与非阻塞:调用 API 时是否需要等待完成时才返回

4. send/sendto 的一般返回情况:

          非阻塞或超时——根据当前缓冲区空闲长度,尽力向套接字缓冲区拷贝,完成了多少算多少,立返回

          阻塞——完成所有数据的拷贝,才返回。如果现在空闲区大小不够,会等待至空闲区够了并拷贝,完成拷贝后返回

          tcp 是数据流,所以 send 的数据可以很大,而不会返回消息过长的错误;

          udp 因为仅组装成一个数据报,不能够分开多次发送,所以如果发送的数据量大于缓冲区长度,会立即返回消息过长的错误。

          非阻塞的发送可以是套接字级别的,通过 setsockopt 设置;也可以是消息级别的,通过 send 调用时的 MSG_DONTWAIT 标记

          -- 可以用异步方式,将套接字设置为非阻塞,但是需要注意检查 send 函数的返回值,验证 recv 收到的包的完整性

5. udp 下也可以使用 connect,同 tcp 相比,并没有握手过程,只是设定了套接字数据结构里面的远端地址部分

6. 在 tcp 套接字被 shutdown 后,调用读写该套接字的 API 除了返回 EPIPE 错误外,还会产生 SIGPIPE 信号(默认操作是退出进程)。可以在调用 API 时,通过 MSG_NOSIGNAL 标记来告知内核,无需发出这一信号。

7. udp 收包时,如果缓冲区大小比包长要小,那其行为是未定义的,建议最好一次收个够

8. tcp 发包时,担心因为包太小无法即时发送出去的话,可以设置 TCP_NODELAY 套接字选项

9. udp 发包过快会造成本地或远端被“淹没”。考虑一个 udp 服务器,如果接收缓冲区满了,此时还有 udp 数据到达,则协议栈会丢弃新到达的数据。(仅从机器负载去看,难以断定是否会“淹没”,只能估算;淹没发生时,进程通常忙于干其他事情或被阻塞,因此从可控的角度来讲,只好尽量降低 CPU 负载、尽量采用异步)

    udp 丢包的几种情况:网络导致,缓冲区长度不够长导致(rmem_max、SOL_SNDBUF),缓冲区已满

10. tcp connect 时,默认超时因系统不同而不同,一般都要那么几分钟,如果想要主动控制这个超时,有几种方法:修改内核参数、使用异步的 select 和 epoll 查看是否返回套接字可写,如果是 linux 环境,那么 SOL_SNDTIMEO 选项也能起作用。

11. linux下多个子进程可以竞争accept同一个套接字,进程/线程池基本就是这样一种思路,先fork几个再让它们都竞争accept。监视客户端的数量,可以动态地增加、减少进程数。

12. 异步connect时,如果超时会返回一个出错事件,错误码被置为EINPROGRESS

13. 编写一个完善的服务器,要考虑:常见信号是否已经捕获并处理(如SIGSEGV、SIGCHLD、SIGPIPE、SIGTERM、SIGINT等),系统API的返回值是否进行了合理的检查,日志体系是否完善。如果使用了epoll,还要对错误类事件统一处理。

14. 对TCP的情况,如果使用KEEPALIVE选项,协议栈会探测链接的对端是否有响应,如果没有的话会返回套接字可读,receive返回错误。

 


你可能感兴趣的:(数据结构,编程,api,网络,tcp,服务器)