第7节包传输与流传输

你可能需要理解这句话：TCP是流传输协议，UDP是包传输协议。

1：TCP流传输协议？、

打个比方比喻TCP，你家里有个蓄水池，你可以里面倒水，蓄水池上有个龙头，你可以通过龙头将水池里的水放出来，然后用各种各样的容器装（杯子、矿泉水瓶、锅碗瓢盆）接水。
上面的例子中，往水池里倒几次水和接几次水是没有必然联系的，也就是说你可以只倒一次水，然后分10次接完。另外，水池里的水接多少就会少多少；往里面倒多少水，就会增加多少水，但是不能超过水池的容量，多出的水会溢出。
结合TCP的概念，水池就好比接收缓存，倒水就相当于发送数据，接水就相当于读取数据。好比你通过TCP连接给另一端发送数据，你只调用了一次write，发送了100个字节，但是对方可以分10次收完，每次10个字节；你也可以调用10次write，每次10个字节，但是对方可以一次就收完。（假设数据都能到达）但是，你发送的数据量不能大于对方的接收缓存（流量控制），如果你硬是要发送过量数据，则对方的缓存满了就会把多出的数据丢弃。
这种情况是设置非阻塞I/O模型，会把内存耗尽，因为socket是存在内核中的。

客户端发送字节流时，TCP会保证服务端按顺序接收到全部的字节流，其他诸如数据包的大小等，TCP协议对我们来说是透明的，我们可以全部不考虑。
    通俗点说，我们发送数据只需要调用send函数，我们只需要关注send函数的返回值，从而知道了发送了多少个字节，在服务端，我们调用recv函数，我们只需要关注recv函数的返回值，从而知道接收了多少个字节，其他情况通通不管。
   在TCP通信过程中，我们不需要关心（也没法关心，但可以设置）数据包的大小，个数，我们只需要在客户端建立一个缓冲区不断发送，在服务端建立一个缓冲区不断接收就够了，当然，我们还可以定义一个包头，来实现诸如发送文件这样更强大的功能。

2：UDP数据报传输协议？

UDP和TCP不同，发送端调用了几次write，接收端必须用相同次数的read读完。UPD是基于报文的，在接收的时候，每次最多只能读取一个报文， 报文和报文是不会合并的，如果缓冲区小于报文长度，则多出的部分会被丢弃。也就说，如果不指定MSG_PEEK标志，每次读取操作将消耗一个报文。

3：为何你本机传输没问题，而两台计算机间传输就出问题了？

其实，这种不同是由TCP和UDP的特性决定的。TCP是面向连接的，也就是说，在连接持续的过程中，socket中收到的数据都是由同一台主机发出的(劫持什么的不考虑)，因此，知道保证数据是有序的到达就行了，至于每次读取多少数据自己看着办。

而UDP是无连接的协议，也就是说，只要知道接收端的IP和端口，且网络是可达的， 任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。比如，主机A向发送了报文P1，主机B发送了报文P2，如果能够 读取超过一个报文的数据，那么就会将P1和P2的数据合并在了一起，这样的数据是没有意义的。

4：为什么

其实，这种不同是由TCP和UDP的特性决定的。
TCP是面向连接的，也就是说，在连接持续的过程中，socket中收到的数据都是由同一台主机发出的（劫持什么的不考虑），因此，知道保证数据是有序的到达就行了，至于每次读取多少数据自己看着办。
而UDP是无连接的协议，也就是说，只要知道接收端的IP和端口，且网络是可达的，任何主机都可以向接收端发送数据。这时候，如果一次能读取超过一个报文的数据，则会乱套。
比如，主机A向发送了报文P1，主机B发送了报文P2，如果能够读取超过一个报文的数据，那么就会将P1和P2的数据合并在了一起，这样的数据是没有意义的。

5：带来的问题

由于TCP"流"的特性以及网络状况,在进行数据传输时会出现以下几种情况.
假设我们连续调用两次send分别发送两段数据data1和data2,在接收端有以下几种接收情况(当然不止这几种情况,这里只列出了有代表性的情况).
A.先接收到data1,然后接收到data2.
B.先接收到data1的部分数据,然后接收到data1余下的部分以及data2的全部.
C.先接收到了data1的全部数据和data2的部分数据,然后接收到了data2的余下的数据.
D.一次性接收到了data1和data2的全部数据.
对于A这种情况正是我们需要的,不再做讨论.对于B,C,D的情况就是大家经常说的"粘包",就需要我们把接收到的数据进行拆包,拆成一个个独立的数据包.为了拆包就必须在发送端进行封包.
另:对于UDP来说就不存在拆包的问题,因为UDP是个"数据包"协议,也就是两段数据间是有界限的,在接收端要么接收不到数据要么就是接收一个完整的一段数据,不会少接收也不会多接收.
为什么会出现B.C.D的情况：
"粘包"可发生在发送端也可发生在接收端.
1.由Nagle算法造成的发送端的粘包:Nagle算法是一种改善网络传输效率的算法.简单的说,当我们提交一段数据给TCP发送时,TCP并不立刻发送此段数据,而是等待一小段时间,看看在等待期间是否还有要发送的数据,若有则会一次把这两段数据发送出去.这是对Nagle算法一个简单的解释,详细的请看相关书籍.象C和D的情况就有可能是Nagle算法造成的.
2.接收端接收不及时造成的接收端粘包:TCP会把接收到的数据存在自己的缓冲区中,然后通知应用层取数据.当应用层由于某些原因不能及时的把TCP的数据取出来,就会造成TCP缓冲区中存放了几段数据.

6.区别

流式套接字要分客户和服务器，而数据报不用分
流式套接字适合传输数据量大的，而数据报套接字适合传递数据量少的
流式套接字建立麻烦，数据报套接字建立简单
客户的流式套接字只能向一个方向传递，数据报套接字可以接受任何方向的来得数据，并可以向任何地址发送数据报
 
流套接字比数据报套接字好，这样你可以不必管理底层细节，只需要相信TCP就可以保证传送的数据是依次，可靠的传送的，缺点是效率相对数据报套接字低。
使用数据报套接字，可以让你更快，但你得自已保证数据是否依次，准确的传送来的，
如使用数据报套接字，你可能先收到后发的，后收到先发的，还有可能收漏，
 
数据报套接字是用来发送数据报的，是面向无连接不可靠的传输（在今天这个网络里，其实已经相当可靠）
流套接字是面向连接可靠的传输。服务器通过转发实现一个客户与另一个客户的数据传送。当向另一个客户转发时，他必须知道对方IP（或套接字等），所以要求转发的客户必须提供关于接受方的信息，否则服务器不知道向哪转发。