TCP 传输策略
防止黏包现象的出现
当窗口数为 0 时，发送者不能正常发送数据段，除非:
-Urgent数据。比如，用户想杀掉远端机器上的进程的时候，可以发送数据
-发送者可以发送一个字节的数据段，以便让接收者再次发送期待接收的字节号和窗口数（避免死锁）
考虑一个指向某交互式编辑器（远程）的TELNET 连接，该编辑器对用户的每次击键都作出响应，在最坏的情况下：
当用户敲入一个字符的时候，被送到传输实体，创建一个21字节的数据段，在传到网络层，变成了41字节的IP分组
接收方（运行着编辑器的远端机）收到这个信息后，会立发送一个40字节的确认分组 （20字节的 TCP段头和20字节的IP头）
随后，当编辑器读取出这个字节，TCP实体发送一个窗口更新，
这个分组也是40字节
最后，当编辑器处理了这个字符，它发送一个41字节的分组作为该字符的回显
总共累计起来，对于每个敲入的字符，需要至少 162 字节的带宽（还没有考虑到链路层的开销），发送4个数据段。
远程交互telnet的最坏情形图示
怎样优化接收端
接收端可以推迟500ms发送确认分组和窗口更新窗口，以便可以免费搭载在处理后的回显分组内（free ride）
怎样优化发送端
Nagle's algorithm (1984):
- 当数据以一次一字节的速度到达的时候，只发送第一个字节，然后将后续的字节缓存起来，直到发出的字节得到确认
- 将缓存起来的字节在一个数据段中发出，再继续缓存，直到发出的数据得到确认
- Nagle算法在很多TCP上实现，但是有些时候最好禁用，比如：
当一个X-Windows应用在互联网运行的时候，鼠标的移动事件必须发送给远程计算机，把这些移动事件收集起来一批一
批发送出去，使得鼠标的移动极不连贯
Nagle’s 算法图示
傻瓜窗口综合症
另一个使TCP性能退化的问题是傻瓜窗口综合症（silly window
syndrome problem）：当有大块数据被传递给发送端TCP实体，
但接收端的交互式应用每次只读取一个字节的时候，问题就来了
每次接收1字节
Clark解决方案 ：阻止接收方发送只有1个字节的窗口更新，相反，它必须等待一段时间，当有了一定数量的空间之后再告诉发送方
接收方可以可以维护一个内部缓冲，且阻塞上层应用的
READ 请求，直到它有大块的数据提供
Clark解决方案
发送方和接收方
TCP传输的是全双工的字节流。
TCP适配收发双方的数据流量
-Window size
TCP还需要效率
-发方优化： Nagle’s algorithm
-收方优化： Clark’s solution