关于TCP可靠性传输特性为何在系统内核层实现的疑问

昨天看帖想到一个TCP传输的问题，假设进程A与进程B建立一个TCP连接（A和B在不同的主机），A需要发送数据data到B。假设A的TCP发送缓冲区能容纳data数据的长度，那么用户进程A发送数据到B的过程是，A会使用系统调用把data数据拷贝到系统内核然后返回到应用程序，此时A进程根本就不知道进程B的TCP层是否收到了data数据。因为A进程只保证把data数据拷贝到操作系统内核，发送data数据到B进程是由A进程所在系统内核来完成的。

（在A进程把数据拷贝到内核后假设物理线路出现了问题）那么问题来了，TCP可靠性特性我们该怎么理解。好吧，我对她的理解是TCP可靠性特性是针对操作系统内核层面来说的，因为只有A进程所在系统内核知道B进程的TCP端是否收到了数据data，这个是因为ack。

那么问题又来了，TCP这个特性对应用进程有什么好处呢？假设我们要做一个应用层消息必须到达的应用，站在应用程序的角度传输层使用TCP和UDP好像也没什么区别，因为我们都需要在应用层做消息到达确认。

站在应用进程角度看发送端的传输层发送的数据永远无法保证接收端传输层能接收（假设物理链路有问题），感觉唯一的区别就是操作系统内核知道TCP传输的数据对方端是否收到，可是操作系统内核知道这个信息又有什么好处呢？

我总结一下，其实你的困惑就是：为什么要在TCP协议层（协议栈）来实现消息送达保证机制。

其实，很好理解：我们抛开TCP或UDP本身，可以想象一下，当初网络刚出现的时候，数据可以在两个终端之间传输，这是很神奇的事情。但问题来了，在TCP/IP之前，没有标准的方法保证数据准确被送达。人们后来编写TCP协议的目的，就是为了保证数据被准确、实时、高效的送达，注意“实时”、“高效”这两个字眼。这两个特性显然只有离操作系统内核或硬件越近，才越有可能，至于“准确”，也就是通常理解的消息送达机制，其实无论是应用层还是底层都是可以实现。所以，正如你的困惑，我个人认为，TCP协议的这些机制由系统级协议栈代码来实现，显然就是解决了应用层永远也无法跟底层相比的“实时”、“高效”。

其实，UDP加上QoS这些机制后，也就相当于TCP了，而UDP实际上就是保持了计算机网络技术初期的简单特性，这也是为什么人们会说TCP要比UDP复杂多了。换句话说，UDP加上TCP这些特性，也就成了TCP了。

我说的可能还是有点乱，论坛里的这个系列文章，很好的讲解了TCP的各种特性，你可以好好看看：http://www.52im.net/thread-513-1-1.html

我再补充一下，有空的时候，你可以好好读下《TCP/IP详解》这本书，以及这本书为何被称为神书的原因：其实在那个年代，关于网络方面的编程难度是非常高的，普通的程序员在应用层，其实是很难写出你所说的TCP这些特性的（你可以了解下TCP这些早期的代码都是什么样的大牛写出来的，也只有这些大牛能写的好），之所以从今日的角度看，好像应用层确实可以很容易地实现TCP的这些特性，原因在于：现在的网络编程API经过这么多年的发展，已经越来越易用，也才会发生楼主出现这些困惑了。

实际上，以现在的技术，相信很多人都有种去再造一个TCP这样的协议，但既然已经有了这么好的东西，为何要再重新造轮子？

如果楼主有时间的话，可以直接去看看TCP/IP详细的2、3卷，这两卷连代码实现都为你讲解了。
其实，应用层程序员了解好这些东西的特性用好这些东西就行了，至于它的真正原理，倒是技术之外的事了。
不过，有好学心态很很好的，很多人都缺少这种动力

说实话，很多人都是人云亦云，楼主是个爱动脑的好青年，我了解的不比你多，不敢乱讲误倒楼主，友情帮顶了