是否需要通过 TCP 进行应用级重传和确认?

本文介绍了是否需要通过 TCP 进行应用级重传和确认?的处理方法，对大家解决问题具有一定的参考价值，需要的朋友们下面随着小编来一起学习吧！

问题描述

限时送ChatGPT账号..

我有以下疑问:

1) TCP 是否保证数据包的交付，因此如果使用的传输协议是 TCP，则需要应用级重传.假设我在客户端和服务器之间建立了 TCP 连接，服务器向客户端发送消息.然而，客户端离线并在 10 小时后才返回，那么 TCP 堆栈会处理重新传输并将消息传递给客户端还是服务器上运行的应用程序需要处理它?<​​/p>

2) 与上述问题相关，如果传输协议是 TCP，是否需要应用程序级 ACK.应用程序 ACK 的原因之一是没有它，应用程序将不知道远程端何时收到消息.除此之外还有什么原因吗?意思是消息本身的传递有保证吗?

解决方案

TCP 是否保证数据包的交付，因此如果使用的传输协议是 TCP，则需要应用程序级重传

TCP 保证将消息流字节传送到 TCP 连接另一端的 TCP 层.因此，应用程序不必为重传的细微差别而烦恼.但是，在将其视为绝对答案之前，请阅读我的其余答案.

<块引用>

然而，客户端离线并在 10 小时后才返回，那么 TCP 堆栈会处理重新传输并将消息传递给客户端还是服务器上运行的应用程序需要处理它?<​​/p>

不，不是真的.即使 TCP 对单个 TCP 数据包具有某种程度的重试逻辑，如果远程端点断开连接，它也无法执行重新连接.换句话说，它最终将超时"等待从远程端获得 TCP ACK 并进行几次重试.但最终会放弃并通过socket接口通知应用远程端点连接处于死机或关闭状态.典型的模式是，当客户端应用程序检测到它与服务器的套接字连接丢失时，它要么向应用程序的用户界面报告错误，要么重试连接.无论哪种方式，如何处理失败的 TCP 连接都是应用程序级别的决定.

<块引用>

如果传输协议是 TCP，是否需要应用层 ACK

是的，绝对.大多数客户端-服务器协议都有一些请求/响应消息对的概念.TCP 套接字只能向应用程序指示应用程序发送"的数据是否成功排队到内核的网络堆栈.它不保证远程端套接字顶部的应用程序实际上得到它"或处理它".您在 TCP 之上的协议应该在处理消息时提供某种响应指示.在这里使用 HTTP 作为一个很好的例子.想象一下，如果应用程序向服务器发送 HTTP POST 消息，但没有来自服务器的确认(例如 200 OK).客户端如何知道服务器处理了它?

在网络地址转换器 (NAT) 和代理服务器的世界中，闲置的 TCP 连接(彼此之间没有数据)可能会失败，因为 NAT 或代理代表实际端点关闭连接，因为它认为缺少发送的数据.解决方案是使用某种周期性的ping"和pong"协议，通过这些协议，应用程序可以在没有数据发送的情况下保持 TCP 连接的活动.

I have the following queries:

1) Does TCP guarantee delivery of packets and thus is thus application level re-transmission ever required if transport protocol used is TCP. Lets say I have established a TCP connection between a client and server, and server sends a message to the client. However the client goes offline and comes back only after say 10 hours, so will TCP stack handle re-transmission and delivering message to the client or will the application running on the server need to handle it?

2) Related to the above question, is application level ACK needed if transport protocol is TCP. One reason for application ACK would be that without it, the application would not know when the remote end received the message. Is there any reason other than that? Meaning is the delivery of the message itself guaranteed?

解决方案

Does TCP guarantee delivery of packets and thus is thus application level re-transmission ever required if transport protocol used is TCP

TCP guarantees delivery of message stream bytes to the TCP layer on the other end of the TCP connection. So an application shouldn't have to bother with the nuances of retransmission. However, read the rest of my answer before taking that as an absolute.

However the client goes offline and comes back only after say 10 hours, so will TCP stack handle re-transmission and delivering message to the client or will the application running on the server need to handle it?

No, not really. Even though TCP has some degree of retry logic for individual TCP packets, it can not perform reconnections if the remote endpoint is disconnected. In other words, it will eventually "time out" waiting to get a TCP ACK from the remote side and do a few retries. But will eventually give up and notify the application through the socket interface that the remote endpoint connection is in a dead or closed state. Typical pattern is that when a client application detects that it lost the socket connection to the server, it either reports an error to the user interface of the application or retries the connection. Either way, it's application level decision on how to handle a failed TCP connection.

is application level ACK needed if transport protocol is TCP

Yes, absolutely. Most client-server protocols has some notion of a request/response pair of messages. A TCP socket can only indicate to the application if data "sent" by the application is successfully queued to the kernel's network stack. It provides no guarantees that the application on top of the socket on the remote end actually "got it" or "processed it". Your protocol on top of TCP should provide some sort of response indication when ever a message is processed. Use HTTP as a good example here. Imagine if an application would send an HTTP POST message to the server, but there was not acknowledgement (e.g. 200 OK) from the server. How would the client know the server processed it?

In a world of Network Address Translators (NATs) and proxy servers, TCP connections that are idle (no data between each other) can fail as the NAT or proxy closes the connection on behalf of the actual endpoint because it perceives a lack of data being sent. The solution is to have some sort of periodic "ping" and "pong" protocol by which the applications can keep the TCP connection alive in the absences of having no data to send.

这篇关于是否需要通过 TCP 进行应用级重传和确认?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！