大型网站服务器价格在线营销单页网站制作
三次握手，四次挥手
三次握手示意图：
SYN、ACK是TCP协议头里面的标志位
同步 SYN：仅在三次握手建立 TCP 连接时有效。当 SYN = 1 而 ACK = 0 时，表明这是一个连接请求报文段，对方若同意建立连接，则应在相应的报文段中使用 SYN = 1 和 ACK = 1。因此，SYN 置1 就表示这是一个连接请求或连接接受报文
ACK：确认 ACK：仅当 ACK=1 时确认号字段才有效，TCP 规定，在连接建立后所有传达的报文段都必须把 ACK 置1
ack是32位确认号，期望收到对方下一个报文段的第一个数据字节的序号每当有ACK了，确认号都要加一
客户端: CLOSED -> SYN-SEND -> ESTABLISHED
服务端：CLOSED -> LISTEN -> SYN-RECV -> ESTABLISHED
为什么不能是其他次数？
通信双方都要知道对方具备发送和接受的能力，这样才是一个良好的关系
两次可能会导致资源的浪费，因为服务器不知晓发送端是否具有接收信息的能力，所以每一次接收信息他都会发一个确认收到和请求SYN的信息。
四次是可以的，只是会造成资源的浪费，最后优化成三次
四次挥手示意图
无论是hi哪一方都可以主动发出断开连接
断开连接的一方 ： FIN_WAIT_1 -> FIN_WAIT_2 -> TIME_WAIT
被断开的一方：CLOSE_WAIT -> LAST_ACK
为什么不能是其他次数？
TCP是全双工通信，可以双向传输数据，任何一方都可以再数据传送结束之后发出连接释放的通知，待接收方确认之后进入半关闭状态。这会可能接收方还有信息要发给请求断链方，因此还没有向对方发一个“我也请求断链”的消息。当接收方发的东西发完之后，接收方就可以向请求断联方发FIN“我要断开”的消息，主动断开连接的一方，最后会进入一个 TIME_WAIT状态，这个状态会持续2msl
为什么要等2ml?
当 TCP 连接主动关闭方接收到被动关闭方发送的 FIN 和最终的 ACK 后，连接的主动关闭方必须处于TIME_WAIT 状态并持续 2MSL 时间这样就能够让 TCP 连接的主动关闭方在它发送的 ACK 丢失的情况下重新发送最终的 ACK。因为被断的一方如果没收到主动断一方的最后一个ACK的话，会再次发送一次FIN，这个时间就是留在这里用的。如果不等，一方结束了另一方没结束，那么就一直浪费资源
TCP的流量控制
滑动窗口是 TCP 中实现诸如 ACK 确认、流量控制、拥塞控制的承载结构- TCP 中采用滑动窗口来进行传输控制，滑动窗口的大小意味着接收方还有多大的缓冲区可以用于接收数据。发送方可以通过滑动窗口的大小来确定应该发送多少字节的数据。当滑动窗口为 0时，发送方一般不能再发送数据报
滑动窗口可以理解为缓冲区
这个滑动窗门主要是接收方来用的。
TCP通信实例图：
win就代表接收方的滑动窗口还有多少空余可以接受的地方，这样发送方也能对应调整
TCP通信并发
要点
- 利用多线程或者多进程的方式，实现多个客户端对服务器的访问操作，每次一有客户端连接，就创建新的进程或者线程
- 回收资源，利用信号SIGCHILD+waitpid实现，在循环while(1)内部
- 当每次释放进程资源的时候，会使得创建新进程的while（1)里面的accept被信号软中断，这会导致这个的accept出错，这个时候需要设置当errorno=ENTER的时候，再重新选换一次创建一个新的accept等待阻塞
多进程开发
遇到的问题，及解决
- 断开连接后，服务器端如何处理子进程，回收资源？
- 使用信号处理
- 使用信号捕捉回收子进程资源后，出现服务端
accept: Interrupted system call，且不能有新客户端连接，如何解决？- 产生
EINTR信号，具体说明通过man 2 accept查看 - 在
accept返回值处进行判断处理，不输出错误即可
- 产生
- 当停止所有的客户端连接后，出现
read: Connection reset by peer，如何解决？- 产生的原因：连接断开后的读和写操作引起的
- 简单修改：将客户端中休眠语句的位置进行更改
- 方法：[261]Connection reset by peer的常见原因及解决办法
- 解决上一个问题后，服务端出现两次
client closed...，如何解决？- 是因为在关闭连接后，应该退出循环，所以在该
printf语句后，添加break即可
- 是因为在关闭连接后，应该退出循环，所以在该
多线程开发
思路
-
服务端使用一个主线程，多个子线程
-
主线程负责等待并接受客户端的连接
-
子线程：完成通信，接受一个客户端连接，就创建一个子进程用于通信
-
-
客户端不需要改变（同一对一通信）