问题:
在看thrift协议的时候,突然想到差错控制为什么要在传输层(单指tcp)做,而不是更上一层的应用层?
思路:
后来仔细一想,虽然客户端在打包的时候,是从应用层开始从上往下填充的,但是服务端解析的时候是反着来的,从下往上的,这也是为什么TCP/IP被称为协议栈的原因之一。(刚好满足栈的特性)
所以,我们在进行差错控制的时候,比如看序号有没有乱,是先解析到tcp的,此时应用层还在tcp的数据段里面没有解析出来,这时候在服务端看来,它看到的就是一个单纯的网络段–tcp报文,跟业务是没有关系的,它通过tcp头部的各种信息来判断差错,而不关心业务具体内容(http的数据)。
这样显然是更有道理的,
一方面,如果tcp都查出来问题了(丢包、乱序),应用层就完全不用解析了,解析出来也不对。
另一方面,应用层以下:tcp、ip这些都是操作系统层面实现的,既然在OS层实现,就相当于一个通用的”平台“,不管你是什么业务,丢包乱序之后,我(OS)都可以进行差错控制,松耦合于业务。
所以,像udp这种要保证可靠传输的话,OS层的内容一般动不了,也就是说只能在应用层想办法。
另外,为什么不把差错控制下移,在IP层做差错控制?这样不是省掉tcp的一层封装了吗?
现代的tcp/ip已经做的很精简了(仅网络层次而言) IP层有IP的作用,路由和差错控制也没有任何关系,IP层保障的是网络传输过程,关注的是顺利到达目的地,关注的是传输路径、过程, 差错控制不应该在传输路径上做,当然它也做不了, 所以只能放到端上去做,一旦报文到达端上之后,IP层的生命周期理论上已经结束了,该tcp上场了。
这两个(路由和差错控制,就像上面说的差错控制和业务的关系一样)显然也应该是松耦合的。