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