Can I make TCP Keep-Alive symmetric?
I have a server (nginx on Ubuntu) which has listen 80 so_keepalive=4m::;. I have a windows client which I set the TCP Keep-Alive timeout with http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx . I set the server timeout to 4 minutes and the client timeout to 5 minutes. What I notice now, capturing the data between them with Wireshark is that after 4 minutes the server sends the TCP Keep-Alive and then one minute later (at 5 minutes from the start) the client sends its own TCP Keep-Alive. Why isn't the timer reset upon receipt of the servers Keep-Alive packet? Is there any way to change this behavior?
linux windows sockets nginx tcp
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
add a comment |
I have a server (nginx on Ubuntu) which has listen 80 so_keepalive=4m::;. I have a windows client which I set the TCP Keep-Alive timeout with http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx . I set the server timeout to 4 minutes and the client timeout to 5 minutes. What I notice now, capturing the data between them with Wireshark is that after 4 minutes the server sends the TCP Keep-Alive and then one minute later (at 5 minutes from the start) the client sends its own TCP Keep-Alive. Why isn't the timer reset upon receipt of the servers Keep-Alive packet? Is there any way to change this behavior?
linux windows sockets nginx tcp
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
add a comment |
I have a server (nginx on Ubuntu) which has listen 80 so_keepalive=4m::;. I have a windows client which I set the TCP Keep-Alive timeout with http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx . I set the server timeout to 4 minutes and the client timeout to 5 minutes. What I notice now, capturing the data between them with Wireshark is that after 4 minutes the server sends the TCP Keep-Alive and then one minute later (at 5 minutes from the start) the client sends its own TCP Keep-Alive. Why isn't the timer reset upon receipt of the servers Keep-Alive packet? Is there any way to change this behavior?
linux windows sockets nginx tcp
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
I have a server (nginx on Ubuntu) which has listen 80 so_keepalive=4m::;. I have a windows client which I set the TCP Keep-Alive timeout with http://msdn.microsoft.com/en-us/library/windows/desktop/dd877220(v=vs.85).aspx . I set the server timeout to 4 minutes and the client timeout to 5 minutes. What I notice now, capturing the data between them with Wireshark is that after 4 minutes the server sends the TCP Keep-Alive and then one minute later (at 5 minutes from the start) the client sends its own TCP Keep-Alive. Why isn't the timer reset upon receipt of the servers Keep-Alive packet? Is there any way to change this behavior?
linux windows sockets nginx tcp
linux windows sockets nginx tcp
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
edited Nov 15 '18 at 1:09
Alexis Wilke
10.1k34180
10.1k34180
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
asked Sep 12 '14 at 0:51
chacham15chacham15
6,3961575160
6,3961575160
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The TCP Keep-Alives is kind of a hack that was added later to the protocol.
There is the relevant RFC-1122 paragraph about the question you have:
4.2.3.6 TCP Keep-Alives
[...snip...]
To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains
SEG.SEQ = SND.NXT-1and may or may not contain one garbage octet of data. Note that on a quiet connectionSND.NXT = RCV.NXT, so that thisSEG.SEQwill be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with aRSTinstead of an acknowledgment segment.
[...snip...]
In other words, a TCP Keep-Alive segment uses an old sequence number (SND.NXT-1) and expects a valid reply from it. There isn't really anything else that distinguish that segment from a normal segment. The TCP stack on the other end does not need to implement anything special to know that a Keep-Alive segment was sent. As long as the protocol was properly implemented, with or without the Keep-Alive feature, it will work transparently.
As mentioned in the RFC, there are cases where a TCP implementation will not answer such a request properly unless it includes at least one octet of data. I do not know which ones (Microsoft?)...
Further, the documentation says that only the server side should make use of the Keep-Alive feature. For sure, if you know that a server has the Keep-Alive turned on, then there is no need for you to have it in your client.
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25799104%2fcan-i-make-tcp-keep-alive-symmetric%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The TCP Keep-Alives is kind of a hack that was added later to the protocol.
There is the relevant RFC-1122 paragraph about the question you have:
4.2.3.6 TCP Keep-Alives
[...snip...]
To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains
SEG.SEQ = SND.NXT-1and may or may not contain one garbage octet of data. Note that on a quiet connectionSND.NXT = RCV.NXT, so that thisSEG.SEQwill be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with aRSTinstead of an acknowledgment segment.
[...snip...]
In other words, a TCP Keep-Alive segment uses an old sequence number (SND.NXT-1) and expects a valid reply from it. There isn't really anything else that distinguish that segment from a normal segment. The TCP stack on the other end does not need to implement anything special to know that a Keep-Alive segment was sent. As long as the protocol was properly implemented, with or without the Keep-Alive feature, it will work transparently.
As mentioned in the RFC, there are cases where a TCP implementation will not answer such a request properly unless it includes at least one octet of data. I do not know which ones (Microsoft?)...
Further, the documentation says that only the server side should make use of the Keep-Alive feature. For sure, if you know that a server has the Keep-Alive turned on, then there is no need for you to have it in your client.
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
add a comment |
The TCP Keep-Alives is kind of a hack that was added later to the protocol.
There is the relevant RFC-1122 paragraph about the question you have:
4.2.3.6 TCP Keep-Alives
[...snip...]
To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains
SEG.SEQ = SND.NXT-1and may or may not contain one garbage octet of data. Note that on a quiet connectionSND.NXT = RCV.NXT, so that thisSEG.SEQwill be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with aRSTinstead of an acknowledgment segment.
[...snip...]
In other words, a TCP Keep-Alive segment uses an old sequence number (SND.NXT-1) and expects a valid reply from it. There isn't really anything else that distinguish that segment from a normal segment. The TCP stack on the other end does not need to implement anything special to know that a Keep-Alive segment was sent. As long as the protocol was properly implemented, with or without the Keep-Alive feature, it will work transparently.
As mentioned in the RFC, there are cases where a TCP implementation will not answer such a request properly unless it includes at least one octet of data. I do not know which ones (Microsoft?)...
Further, the documentation says that only the server side should make use of the Keep-Alive feature. For sure, if you know that a server has the Keep-Alive turned on, then there is no need for you to have it in your client.
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
add a comment |
The TCP Keep-Alives is kind of a hack that was added later to the protocol.
There is the relevant RFC-1122 paragraph about the question you have:
4.2.3.6 TCP Keep-Alives
[...snip...]
To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains
SEG.SEQ = SND.NXT-1and may or may not contain one garbage octet of data. Note that on a quiet connectionSND.NXT = RCV.NXT, so that thisSEG.SEQwill be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with aRSTinstead of an acknowledgment segment.
[...snip...]
In other words, a TCP Keep-Alive segment uses an old sequence number (SND.NXT-1) and expects a valid reply from it. There isn't really anything else that distinguish that segment from a normal segment. The TCP stack on the other end does not need to implement anything special to know that a Keep-Alive segment was sent. As long as the protocol was properly implemented, with or without the Keep-Alive feature, it will work transparently.
As mentioned in the RFC, there are cases where a TCP implementation will not answer such a request properly unless it includes at least one octet of data. I do not know which ones (Microsoft?)...
Further, the documentation says that only the server side should make use of the Keep-Alive feature. For sure, if you know that a server has the Keep-Alive turned on, then there is no need for you to have it in your client.
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
The TCP Keep-Alives is kind of a hack that was added later to the protocol.
There is the relevant RFC-1122 paragraph about the question you have:
4.2.3.6 TCP Keep-Alives
[...snip...]
To confirm that an idle connection is still active, these implementations send a probe segment designed to elicit a response from the peer TCP. Such a segment generally contains
SEG.SEQ = SND.NXT-1and may or may not contain one garbage octet of data. Note that on a quiet connectionSND.NXT = RCV.NXT, so that thisSEG.SEQwill be outside the window. Therefore, the probe causes the receiver to return an acknowledgment segment, confirming that the connection is still live. If the peer has dropped the connection due to a network partition or a crash, it will respond with aRSTinstead of an acknowledgment segment.
[...snip...]
In other words, a TCP Keep-Alive segment uses an old sequence number (SND.NXT-1) and expects a valid reply from it. There isn't really anything else that distinguish that segment from a normal segment. The TCP stack on the other end does not need to implement anything special to know that a Keep-Alive segment was sent. As long as the protocol was properly implemented, with or without the Keep-Alive feature, it will work transparently.
As mentioned in the RFC, there are cases where a TCP implementation will not answer such a request properly unless it includes at least one octet of data. I do not know which ones (Microsoft?)...
Further, the documentation says that only the server side should make use of the Keep-Alive feature. For sure, if you know that a server has the Keep-Alive turned on, then there is no need for you to have it in your client.
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
answered Nov 15 '18 at 1:42
Alexis WilkeAlexis Wilke
10.1k34180
10.1k34180
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f25799104%2fcan-i-make-tcp-keep-alive-symmetric%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
