需求 java 中 socket 超时时间是什么样的？ 解决 读写超时 默认为 0，一直阻塞等待，除非使用 setSoTimeout() 来设置超时时间。 连接超时 默认为 135 秒，默认重新发送6次 sync 包。 第一次等待 1秒，第二次等 2秒，第几次就是 2 的 N次方。 参考 【计算机网络】Socket的SO_TIMEOUT与连接超时时间 Socket 基础之超时时间 Java解决Client Socket连接服务端超时问题 java.net.SocketException in Java with Examples java.net.SocketException:Connection reset java.net.SocketException四大异常解决方案 设置socket connect超时时间的几种方法 Android Socket tcp连接状态判断
电脑承受进程数量 1核2GB 可以大约 100 多进程或线程 普通服务器大概是 10倍性能，即 1000 多进程或线程。 IO 多路复用能力 1个进程或线程可以使用多个 TCP。 单进程 select 可以 1024 单进程 poll 可以数千 单进程 epoll 可以百万 fdset 本质上是 int[32] 组成的 bitmap, 刚好对应 1024 个文件描述符。 参考 IO 多路复用 select 模型上
客户端和服务端字符串转字节为啥不一样？ 客户端 struct hostent* h; // 用于存放服务端IP地址(大端序)的结构体的指针。 if ( (h = gethostbyname(argv[1])) == nullptr ) // 把域名/主机名/字符串格式的IP转换成结构体。 { cout << "gethostbyname failed.\n" << endl; close(sockfd); return -1; } memcpy(&servaddr.sin_addr,h->h_addr,h->h_length); // ③指定服务端的IP(大端序)。 服务端 servaddr.sin_addr.s_addr=inet_addr(argv[1]); // ③指定服务端的IP，只能用IP，不能用域名和主机名。 原因 inet_addr 这个只能转换 ip 地址 gethostbyname 可以支持 IP，域名等等。 对于服务端来说，给他 ip 地址就够了。但是对于客户端来说，他需要连接的更多的可能是域名，而不是 IP。 服务端为什么也要设置 IP 如果服务端是运行于多网卡的服务器上面，那么必须要明确当前这个服务端是服务于那一个网段的，通过设置 servaddr.sin_addr.s_addr 就可以确定服务的网段了。 参考 万恶的结构体
getsockopt 作用 可以获取 socket 缓冲区大小。 int bufsize = 0; socklen_t optlen = sizeof(bufsize); getsockopt(sockfd, SOL_SOCKET, SO_SNDBUF, &bufsize, &optlen); // 获取发送缓冲区的大小。 cout << "send bufsize=" << bufsize << endl; getsockopt(sockfd, SOL_SOCKET, SO_RCVBUF, &bufsize, &optlen); // 获取接收缓冲区的大小。 cout << "recv bufsize=" << bufsize << endl; send 会阻塞吗？ 如果发送太快，接受太慢，send 也会被阻塞。 send 之后，立即关闭，能接收到吗？ 可以的，因为 send 是把数据写入到内核中的发送缓冲区，就算立即关闭，也能接收到。 nagle 算法 在发送一个小于 MSS 长度的包之后，必须收到回复，才能发下一个小包。保证了网络中小包数量得到控制。一般 ACK 大概 40ms. 接收延迟：在接受到一个包之后，会等待 40ms，才会发送 ACK, 这样可以尽量和应用层的回复数据合一个包。 在联机游戏，证券交易等应用场景，时效性要求高，一般会禁用 Nagle 算法。开启 TCP_NODELAY 选项。 #include <netinet/tcp....
netstat 使用 netstat 可以用来查看 socket 状态。 安装 如果系统里面没有，那么 yum install net-tools -y 可以安装。 使用 使用 netstat -a | less 或者 netstat -a | more 来查看。 上半部分的信息是 TCP 相关，下半部分是进程间的 socket 通信。 可以观察右边的 listen, established 等状态。 客户端的 port 是客户端系统随机选择的，不要去太过于关注。 port 使用限制 普通权限只能使用 1024 以上端口 root 可以使用 1024 以下的端口。 close 状态是假想状态，不存在的。 listen 的第二个参数作用 第二个参数 + 1 是 established 队列的大小，超过队列的客户端连接状态为 SYN_RCV. 三次握手 客户端申请向服务端的通道 服务端接受了，并且向客户端申请通道 客户端接受了，并给出回应 这样经过三次握手，双方建立了双向通道 四次挥手 A 请求关闭 B 同意关闭单向通道 B 把剩余的数据全部发送。 B 向 A 发送关闭请求 A 发送回应 主动端开的 A 在最后的回应后有个 TIME_WAIT 状态，时间为 2MSL，一个 MSL 在 30秒到1分钟。 服务端主动关闭 会导致 socket 释放，并且 2MSL 后端口才能重用。否则会有 bind 错误提示，并且在 netstat 中可以看到处于 TIME_WAIT 状态。 可以使用 setsockopt 函数，在 bind 之前，可以防止 bind 错误。 客户端主动关闭 没有危害，因为客户端的端口是随机分配端口号的，并且一般用的不多，够用了。...
signal(i, SIG_IGN) 作用 // 忽略全部的信号，不希望被打扰。顺便解决了僵尸进程的问题。 for (int ii=1;ii<=64;ii++) signal(ii,SIG_IGN); kill(0, SIGTERM) 作用 kill(0,SIGTERM); // 向全部的子进程发送15的信号，通知它们退出。 因为在子进程中 SIGTERM 是退出信号。 父进程关掉 clientsocket, 子进程关掉 listensocket int pid=fork(); if (pid==-1) { perror("fork()"); return -1; } // 系统资源不足。 if (pid> 0) { // 父进程。 tcpserver.closeclient(); // 父进程关闭客户端连接的socket。 continue; // 父进程返回到循环开始的位置，继续受理客户端的连接。 } tcpserver.closelisten(); // 子进程关闭监听的socket。 在 /proc/xxx 下面的是进程相关资源，里面的 fd 是根据当前最小可用来递增的。 如果父进程不关 clientsocket, 那么每次 accept 之后，fd 都需要增加一个，然后在后面的 fork 中，这些递增的 fd 也都会被复制到子进程中。对于子进程来说，它不需要其他子进程相关的 =clientsocket=，所以完全是浪费资源。 子进程只需要自己对应的 clientsocket, 不需要 listensocket. listensocket 是专门给父进程用来监听的。 子进程结束需要 return return 0; // 子进程一定要退出，否则又会回到accept()函数的位置。 如果子进程结束没有 return=，让进程退出，那么会在 =while 中重新回到 accept 这个地方，进行了监听，然后 fork 了。...
为什么 TCP 是可靠的通信，服务端每一步都要有回复。 因为服务端可能没有 accept 或者可能忙于其他事情，bug 掉线等等。所以虽然 TCP 本身是可靠的，但是服务器可能是不可靠的。所以为了业务是正常的，就必须在服务端正常应答的情况下，才能继续。 读取文件使用 ifstream 操作 字符串拼接报错？ 一般情况都是只有 char * 和 char * 拼接，才会报错。只要语句中有一个 string, 拼接就不会报错。 参考 实现文件传输功能
封装时 send 函数为啥使用 const string & buf 作为参数类型 bool send(const string &buffer) // buffer不要用const char * const string & buf 既可以接收 string 也可以接受 char *. 估计是对 char * 进行了隐式转换成了 string. send 函数的参数为啥是 buf.data() 和 buf.size(), 而不是 buf.c_str() 和 buf.length if ((::send(m_clientfd,buffer.data(),buffer.size(),0))<=0) return false; buf.data() 和 buf.c_str() 都指向的是内容的指针，但是语义不一样。 data 表示的就是原始数据，而 c_str 表示的是转化为 char *. buf.size() 的语义是原始内容的大小，而 length 表示的是字符串的长度。 所以都是因为语义不合适。虽然都能用，但是确实不合适。 recv 函数的参数为啥是 & buf[0] 而不是 buf.c_str() 或者 buf.data() int readn=::recv(m_clientfd,&buffer[0],buffer.size(),0); // 直接操作buffer的内存。 因为后面两种返回的都是带有 const, 只有 &buf[0] 才没有 const, 适合对内容进行修改。...
需求 选择消息队列或者 socket 来传递信息，速度哪个快？ 解决 长连接时， socket 比 queue 慢 10% 短连接时，速度更慢。 建议: 长连接，使用 socket，毕竟方便，效率也没有低太多。 短连接，使用 queue，或者数据库连接池。 参考 【本文已迁移到“程序员文摘” http://programmerdigest.cn/category/lajp】Linux下消息队列和socket绝对速度比拼 【转】Linux下消息队列和socket绝对速度比拼 数据库连接池学习笔记（一）：原理介绍+常用连接池介绍 用消息队列和socket实现聊天系统