TCP 套接字中的I/O缓冲
TCP套接字的数据收发无边界。服务器端即使调用1次write函数传输40字节的数据，客户端也有可能通过4次read函数调用每次读取10字节。但此处也有一些疑问，服务器端一次性传输了40字节，而客户端居然可以缓慢地分批接收。客户端接收10字节后，剩下的30字节在
何处等候呢？是不是像飞机为等待着陆而在空中盘旋一样，剩下30字节也在网络中徘徊并等待接收呢？
实际上， write函数调用后并非立即传输数据， read函数调用后也并非马上接收数据。更准确地说，如图所示， write函数调用瞬间，数据将移至输出缓冲； read函数调用瞬间，从输入缓冲读取数据。
调用write函数时，数据将移到输出缓冲，在适当的时候（不管是分别传送还是一次性传送）传向对方的输入缓冲。这时对方将调用read函数从输入缓冲读取数据。这些I/O缓冲特性可整理如下。
- I/O缓冲在每个TCP套接字中单独存在。
- I/O缓冲在创建套接字时自动生成。
- 即使关闭套接字也会继续传递输出缓冲中遗留的数据。
- 关闭套接字将丢失输入缓冲中的数据。
“不会发生超过输入缓冲大小的数据传输。”
根本不会发生这类问题，因为TCP会控制数据流。TCP 中有滑动窗口(Sliding Window) 协议，用对话方式呈现如下。
- 套接宇A:”你好，最多可以向我传递50字节。”
- 套接宇B: “OK!”
- 套接宇A:” 我腾出了20 字节的空间，最多可以收70字节。”
- 套接宇B: “OK!”
Write 函数返回的时间点
write 函数和Windows 的send 函数并不会在完成向对方主机的数据传输时返回，而是在数据移到输出缓冲时。但TCP 会保证对输出缓冲数据的传输，所以说write 函数在数据传输完成时返回。要准确理解这句话。
TCP套接字从创建到消失所经过程分为如下3步。
- 与对方套接字建立连接。
- 与对方套接字进行数据交换。
- 断开与对方套接字的连接。
TCP 内部工作原理1: 与对方套接字的连接
三次握手
TCP 内部工作原理2: 与对方主机的数据交换
图给出了主机A分2次（分2个数据包）向主机B传递200字节的过程。首先，主机A通过1个数据包发送100个字节的数据｀ 数据包的SEQ为1200 。主机B为了确认这一点，向主机A发送ACK1301 消息。
此时的ACK号为1301而非1201, 原因在千ACK号的增蜇为传输的数据字节数。假设每次ACK号不加传输的字节数，这样虽然可以确认数据包的传输，但无法明确100字节全都正确传递还是丢失了一部分，比如只传递了80字节。因此按如下公式传递ACK消息：
ACK 号 = SEQ 号＋ 传递的宇节数+ 1
最后加1 是为了告知对方下次要传递的SEQ号。
下面分析传输过程中数据包消失的情况。
上图表示通过SEQ 1301 数据包向主机B传递100字节数据。但中间发生了错误，主机B未收到。经过一段时间后，主机A仍未收到对于SEQ 1301 的ACK确认，因此试着重传该数据包。为了完成数据包重传， TCP套接字启动计时器以等待ACK应答。若相应计时器发生超时(Time-out!)则重传。
TCP 的内部工作原理3: 断开与套接字的连接
三次握手：
A:”喂，你听得到吗？”A->SYN_SEND
B:”我听得到呀，你听得到我吗？”应答与请求同时发出 B->SYN_RCVD | A->ESTABLISHED
A:”我能听到你，今天balabala……”B->ESTABLISHED
四次挥手：
A:”喂，我不说了。”A->FIN_WAIT1
B:”我知道了。等下，上一句还没说完。Balabala…..”B->CLOSE_WAIT | A->FIN_WAIT2
B:”好了，说完了，我也不说了。”B->LAST_ACK
A:”我知道了。”A->TIME_WAIT | B->CLOSED
A等待2MSL,保证B收到了消息,否则重说一次”我知道了”,A->CLOSED
TCP三次握手：
第一次：客服端向服务器发送请求命令syn;
第二次：服务器应客户端请求ack，同时向客户端发送请求syn；
第三次：客户端响应服务器的请求ack；
四次挥手：
第一次：客户端向服务器发送fin用来关闭服务器和客户端的数据传送；
第二次：服务器接收到fin并向服务器发送ack；
第三次：服务器关闭与客户端的连接，并发送fin给客户端；
第三次：客户端发送ack报文确认
Original: https://blog.51cto.com/u_13267193/5371291
Author: QtHalcon
Title: 网编(4)：TCP原理
原创文章受到原创版权保护。转载请注明出处：https://www.johngo689.com/517518/
转载文章受原作者版权保护。转载请注明原作者出处！