TCP的传输策略是什么？
window size流控过程：TCP是以数据段的形式传输数据的，一个数据段包含很多个字节，相当于批量传输为避免大量数据淹没接收方，采用流控技术，利用的是段头中的一个字段叫窗口尺寸(window size)一个简单例子从上往下过程：sender发送了一个2K的数据，因为SEQ=0，所以这个2K的字节编号是从0一直到2047这个数据到达receiver之后receiver的内存就被占据了一半，还剩下2K，所以这个接收方会回发一个确认：ACK=2048，WIN=2048，分别表示（累计）确认和剩下空间的大小sender再次发送了一个2K的数据，接收方的缓存全部被充满，会发确认：ACK=4096，WIN=0过一段时间接收方对缓存里面的数据进行了处理，从而空出了2K的空间，于是它马上发送了一个更新窗口，当然，这个更新窗口数据段里面WIN=2048，而中间因为没有再接受数据所以ACK=4096不变……别忘了TCP传输是双工的，也就是说sender/receiver可以交换，它们可以互为收发方一些发送策略：当窗口数为0时发送者不能正常发送数据段，除非发送紧急(Urgent)数据（例如用户想杀掉远端机器上的进程的时候）发送者可以发送一个字节的数据段，以便让接收者再次发送期待接收的字节号和窗口数（避免死锁）发送者不需要马上发送应用程序产生的数据，接收者也不需要马上发送应答（当收到数据的时候）接收方/发送方的优化远程交互telnet的最坏情形图示：优化方法：接收端可以推迟500ms发送确认分组和窗口更新窗口，以便可以免费搭载在处理后的回显分组内(free ride)发送端优化Nagle算法当数据以一次一字节的速度到达的时候，只发送第一个字节，然后将后续的字节缓存起来，直到发出的字节得到确认将缓存起来的字节在一个数据段中发出，再继续缓存，直到发出的数据得到确认Nagle算法在很多TCP上实现，但是有些时候最好禁用，例如当一个X-Windows应用在互联网运行的时候，鼠标的移动事件必须发送给远程计算机，把这些移动事件收集起来一批一批发送出去，使得鼠标的移动极不连贯傻瓜窗口综合症有大块数据被传递给发送端TCP实体，然而接收端的交互式应用每次只读取一个字节的时候，如下Clark解决方案 ：阻止接收方发送只有1个字节的窗口更新，它必须等待一段时间，当有了一定数量的空间之后再告诉发送方总结。
所谓流量控制就是让发送发送速率不要过快，让接收方来得及接收。利用滑动窗口机制就可以实施流量控制。原理这就是运用TCP报文段中的窗口大小字段来控制，发送方的发送窗口不可以大于接收方发回的窗口大小。考虑一种特殊的情况，就是接收方若没有缓存足够使用，就会发送零窗口大小的报文，此时发送放将发送窗口设置为0，停止发送数据。
之后接收方有足够的缓存，发送了非零窗口大小的报文，但是这个报文在中途丢失的，那么发送方的发送窗口就一直为零导致死锁。解决这个问题，TCP为每一个连接设置一个持续计时器（persistence timer）。只要TCP的一方收到对方的零窗口通知，就启动该计时器，周期性的发送一个零窗口探测报文段。对方就在确认这个报文的时候给出现在的窗口大小（注意：TCP规定，即使设置为零窗口，也必须接收以下几种报文段：零窗口探测报文段、确认报文段和携带紧急数据的报文段）。
TCP原理应用层向TCP层发送用于网间传输的、用8位字节表示的数据流，然后TCP把数据流分区成适当长度的报文段（通常受该计算机连接的网络的数据链路层的最大传输单元（MTU）的限制）。之后TCP把结果包传给IP层，由它来通过网络将包传送给接收端实体的TCP层。TCP为了保证不发生丢包，就给每个包一个序号，同时序号也保证了传送到接收端实体的包的按序接收。
然后接收端实体对已成功收到的包发回一个相应的确认（ACK）；如果发送端实体在合理的往返时延（RTT）内未收到确认，那么对应的数据包就被假设为已丢失将会被进行重传。TCP用一个校验和函数来检验数据是否有错误；在发送和接收时都要计算校验和。解释1、比如发送端能发送5个数据，接收端也能收到5个数据，给个确认（ack）给发送端，确认我收到5个数据。
如果网络通信出现繁忙或者拥塞的时候，接收端只能收3个数据，接受端给个确认我只能收3个数据，那么发送端就自动调整发送的窗口为3，当线路又恢复通畅的时候，接受端又可以受到5个数据，那它会给确认给发送端，告诉它我的窗口为5，那发送端就把窗口又调整会5，这样进行流量控制的2、比如说发送端窗口为3，发送到接收端，接收端的接收窗口为5的话，接受数据，并且会给发送端一个ack（确认）告诉发送端我的窗口为5，发送端收到确认后会把自己的发送端窗口调整为5~~这样就可以加速数据传输了拓展资料TCP（Transmission Control Protocol 传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议，由IETF的RFC 793定义。
在简化的计算机网络OSI模型中，它完成第四层传输层所指定的功能，用户数据报协议（UDP）是同一层内另一个重要的传输协议。在因特网协议族（Internet protocol suite）中，TCP层是位于IP层之上，应用层之下的中间层。不同主机的应用层之间经常需要可靠的、像管道一样的连接，但是IP层不提供这样的流机制，而是提供不可靠的包交换。
TCP传输协议中如何解决丢包问题？
目前我们的计算机网络体系是一种分层结构，一共七层！下层为上层提供服务！比如连接，传输等！而TCP属于第四层传输层！传输层的任务就是网络上提供完整的数据传送！TCP是一个面向连接的可能的传输层协议！来自上层的数据到达传输层后首先双方发送同步数据包建立连接，再有TCP分组分片！把整个的数据分成符合大小的块，然后分别传送，在TCP的头部有记录顺序的序列号，有控制传送速度的滑动窗口，校验和等信息！一个或多个块到达接收端后，由接收端检验数据包的正确性，然后发送相应序列号的确认，没有被确认的序列号数据块将被重新传送来保证数据的完整性！同时接收端可以根据自己的缓冲区大小，发送改变相应的滑动窗口数据值以避免发送端发送速率过快而是接受端没有缓冲而丢包！。
怎么解决TCP网络传输「粘包」问题？
TCP粘包是指发送方发送的多个数据包到接收方后粘连在一起，导致数据包不能完整的提现发送的数据。 TCP协议TCP是一个面向连接的传输层协议，不属于ISO制定的协议集。TCP协议在商业界和工业界的成功应用，使它成为事实上的网络标准，广泛应用于各种网络主机间的通信。TCP目标是为用户提供可靠的端到端连接，保证信息有序无误的传输。
TCP为确保可靠性采用了数据编号、校验和计算、数据确认等一系列措施。TCP对传送的每个数据字节都进行编号，并请求接收方回传确认信息（ACK）。发送方如果在规定的时间内没有收到数据确认，就重传该数据。 数据编号使接收方能够处理数据的失序和重复问题。数据误码问题通过在每个传输的数据段中增加校验和予以解决，接收方在接收到数据后检查校验和，若校验和有误，则丢弃该有误码的数据段，并要求发送方重传。
流量控制也是保证可靠性的一个重要措施，若无流控，可能会因接收缓冲区溢出而丢失大量数据，导致许多重传，造成网络拥塞恶性循环。TCP采用可变窗口进行流量控制，由接收方控制发送方发送的数据量。这些可靠性保障措施为用户提供了高可靠性的网络传输服务，但也影响了传输效率。在实际工程应用中，只有关键数据的传输才采用TCP，而普通数据的传输一般采用高效率的UDP。
UDP不会出现粘包问题。UDP支持的是一对多的模式，不会使用块的合并优化算法，所以接收端的skbuff(套接字缓冲区）采用了链式结构来记录每一个到达的UDP包，在每个UDP包中就有了消息头（包含消息来源地址，端口等信息），接收端很容易就能进行区分处理了。粘包出现原因出现粘包现象的原因有很多方面，它既可能由发送方造成的，也可能是由接收方造成的。
发送方原因TCP需要尽可能高效和可靠，默认采用Nagle算法，发送方往往要收集到足够多的数据后合并相连的小数据包，才发送一包数据，这样接收方就收到了粘包数据。但接收方并不知晓发送方合并数据包，并数据包的合并在TCP协议中是没有分界线的，就会导致接收方不能还原其本来的数据包。接收方原因TCP是基于“流”的。
网络传输数据的速度可能会快过接收方处理数据的速度，这时候就会导致，接收方在读取缓冲区时，缓冲区存在多个数据包。在TCP协议中接收方是一次读取缓冲区中的所有内容，就不能反映原本的数据信息。粘包情况有两种：一种是粘在一起的包都是完整的数据包； 一种是粘在一起的包有不完整的包； 不是所有的粘包现象都需要处理如果传输的数据为不带结构的连续流数据（如文件传输），就不必把粘连的包分开（简称分包）。
但实际工程应用中一般为带结构的数据，这时就需要做分包处理。在处理定长结构数据的粘包问题时，分包算法比较简单；在处理不定长结构数据的粘包问题时，分包算法就比较复杂。特别是粘在一起的包有不完整的包的粘包情况，一包数据内容被分在了两个连续的接收包中，处理起来难度较大。实际工程应用中应尽量避免出现粘包现象。为了避免粘包现象，可采取以下几种措施：（1）发送方引起的粘包可通过编程设置来避免。
如：PUSH标志是TCP提供了强制数据立即传送的操作指令，TCP软件收到该操作指令后，就立即将本段数据发送出去，而不必等待发送缓冲区满。缺点：虽然可以避免发送方引起的粘包，但关闭了Negle优化算法，降低了网络发送效率，影响应用程序的性能，一般不建议使用。（2）接收方引起的粘包，可通过优化程序设计、精简接收进程工作量、提高接收进程优先级等措施来及时接收数据，尽量避免出现粘包现象。
缺点：只能减少出现粘包的可能性，但并不能完全避免粘包，当发送频率较高或某个时间段数据包到达接收方较快，接收方还是有可能来不及接收，导致粘包。（3）由接收方控制，将一包数据按结构字段，人为控制分多次接收，然后合并，通过这种手段来避免粘包。缺点：应用程序的效率较低，对实时应用的场合不适合。一种比较周全的对策是：接收方创建一预处理线程，对接收到的数据包进行预处理，将粘连的包分开。
文章TAG：算法 nagel Nagle 例子
