Why does a simple TCP echo server produce two identical ACKs for one received byte?

Question

I wrote a simple tcp echo server and a client for it. You'r able to see the code below.

I used tcpdump to monitor packets they produce and found that the server generates two identical tcp segments. I can't get why. Why does the server do that?

Full tcpdump output:

% sudo tcpdump tcp -i lo0 -vv -K
tcpdump: listening on lo0, link-type NULL (BSD loopback), capture size 262144 bytes
17:48:55.677391 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    localhost.50842 > localhost.43542: Flags [S], seq 1367928603, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 589378679 ecr 0,sackOK,eol], length 0
17:48:55.677562 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    localhost.43542 > localhost.50842: Flags [S.], seq 2031335592, ack 1367928604, win 65535, options [mss 16344,nop,wscale 6,nop,nop,TS val 460658588 ecr 589378679,sackOK,eol], length 0
17:48:55.677588 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.50842 > localhost.43542: Flags [.], seq 1, ack 1, win 6379, options [nop,nop,TS val 589378679 ecr 460658588], length 0
17:48:55.677600 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 1:2, ack 1, win 6379, options [nop,nop,TS val 589378679 ecr 460658588], length 1
17:48:55.677609 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 1, win 6379, options [nop,nop,TS val 460658588 ecr 589378679], length 0
17:48:55.677633 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 2, win 6379, options [nop,nop,TS val 460658588 ecr 589378679], length 0
17:48:56.682095 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 2:3, ack 1, win 6379, options [nop,nop,TS val 589379684 ecr 460658588], length 1
17:48:56.682190 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 3, win 6379, options [nop,nop,TS val 460659593 ecr 589379684], length 0
17:48:57.687118 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 3:4, ack 1, win 6379, options [nop,nop,TS val 589380689 ecr 460659593], length 1
17:48:57.687216 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 4, win 6379, options [nop,nop,TS val 460660598 ecr 589380689], length 0
17:48:58.689423 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 4:5, ack 1, win 6379, options [nop,nop,TS val 589381691 ecr 460660598], length 1
17:48:58.689526 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 5, win 6379, options [nop,nop,TS val 460661600 ecr 589381691], length 0
17:48:59.694227 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 5:6, ack 1, win 6379, options [nop,nop,TS val 589382696 ecr 460661600], length 1
17:48:59.694329 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 6, win 6379, options [nop,nop,TS val 460662605 ecr 589382696], length 0
17:49:00.698944 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 6:7, ack 1, win 6379, options [nop,nop,TS val 589383701 ecr 460662605], length 1
17:49:00.699030 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 7, win 6379, options [nop,nop,TS val 460663610 ecr 589383701], length 0
17:49:01.703046 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.50842 > localhost.43542: Flags [F.], seq 7, ack 1, win 6379, options [nop,nop,TS val 589384705 ecr 460663610], length 0
17:49:01.703146 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 8, win 6379, options [nop,nop,TS val 460664614 ecr 589384705], length 0
17:49:01.710326 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [F.], seq 1, ack 8, win 6379, options [nop,nop,TS val 460664621 ecr 589384705], length 0
17:49:01.710462 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.50842 > localhost.43542: Flags [.], seq 8, ack 2, win 6379, options [nop,nop,TS val 589384712 ecr 460664621], length 0

identical segments (the first row is PUSH,ACK from a client, the next two are ACKs from the server):

17:48:55.677600 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    localhost.50842 > localhost.43542: Flags [P.], seq 1:2, ack 1, win 6379, options [nop,nop,TS val 589378679 ecr 460658588], length 1
17:48:55.677609 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 1, win 6379, options [nop,nop,TS val 460658588 ecr 589378679], length 0
17:48:55.677633 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    localhost.43542 > localhost.50842: Flags [.], seq 1, ack 2, win 6379, options [nop,nop,TS val 460658588 ecr 589378679], length 0

I thought that for one PUSH should be only one ACK. It's not a lag or bug, it repeats all the time.

I'd appreciate your help and useful links!

Server:

import socket

if __name__ == '__main__':
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind(('127.0.0.1', 43542))
    s.listen()

    while True:
        try:
            client, addr = s.accept()
        except Exception:
            s.close()
            break

        result = client.recv(1024, socket.MSG_WAITALL)
        print('message:', result.decode('utf-8'))
        s.close()

Client (sends 1 byte per second):

import socket
import time

if __name__ == '__main__':
    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('127.0.0.1', 43542))
    message = "hello!"
    for i in range(6):
        s.send(message[i].encode('utf-8'))
        time.sleep(1)
    s.close()

UPD.

I've tested it on Debian server and found only one ACK instead of two. I think it's because of my Mac. I'm going to look into it (test system parameters of network stack or something like it).

client's tcpdump sending data to a server on Debian system:

tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:24:40.207410 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 64)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [S], seq 3889671406, win 65535, options [mss 1460,nop,wscale 6,nop,nop,TS val 2610994943 ecr 0,sackOK,eol], length 0
00:24:40.227033 IP (tos 0x28, ttl 52, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [S.], seq 3328477915, ack 3889671407, win 65160, options [mss 1460,sackOK,TS val 574499984 ecr 2610994943,nop,wscale 7], length 0
00:24:40.227193 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [.], seq 1, ack 1, win 2058, options [nop,nop,TS val 2610994962 ecr 574499984], length 0
00:24:40.227265 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 1:2, ack 1, win 2058, options [nop,nop,TS val 2610994962 ecr 574499984], length 1
00:24:40.243140 IP (tos 0x28, ttl 52, id 103, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 2, win 510, options [nop,nop,TS val 574500001 ecr 2610994962], length 0
00:24:41.232539 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 2:3, ack 1, win 2058, options [nop,nop,TS val 2610995968 ecr 574500001], length 1
00:24:41.243272 IP (tos 0x28, ttl 52, id 104, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 3, win 510, options [nop,nop,TS val 574501006 ecr 2610995968], length 0
00:24:42.237958 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 3:4, ack 1, win 2058, options [nop,nop,TS val 2610996973 ecr 574501006], length 1
00:24:42.251029 IP (tos 0x28, ttl 52, id 105, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 4, win 510, options [nop,nop,TS val 574502014 ecr 2610996973], length 0
00:24:43.240398 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 4:5, ack 1, win 2058, options [nop,nop,TS val 2610997976 ecr 574502014], length 1
00:24:43.253882 IP (tos 0x28, ttl 52, id 106, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 5, win 510, options [nop,nop,TS val 574503016 ecr 2610997976], length 0
00:24:44.246149 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 5:6, ack 1, win 2058, options [nop,nop,TS val 2610998981 ecr 574503016], length 1
00:24:44.259739 IP (tos 0x28, ttl 52, id 107, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 6, win 510, options [nop,nop,TS val 574504019 ecr 2610998981], length 0
00:24:45.248612 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 6:7, ack 1, win 2058, options [nop,nop,TS val 2610999984 ecr 574504019], length 1
00:24:45.269530 IP (tos 0x28, ttl 52, id 108, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 7, win 510, options [nop,nop,TS val 574505025 ecr 2610999984], length 0
00:24:46.254825 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [F.], seq 7, ack 1, win 2058, options [nop,nop,TS val 2611000990 ecr 574505025], length 0
00:24:46.269117 IP (tos 0x28, ttl 52, id 109, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [F.], seq 1, ack 8, win 510, options [nop,nop,TS val 574506028 ecr 2611000990], length 0
00:24:46.269564 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [.], seq 8, ack 2, win 2058, options [nop,nop,TS val 2611001005 ecr 574506028], length 0

so, there is only one ACK:

00:24:40.227265 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 53)
    192.168.0.2.55150 > 1.3.3.7.43542: Flags [P.], seq 1:2, ack 1, win 2058, options [nop,nop,TS val 2610994962 ecr 574499984], length 1
00:24:40.243140 IP (tos 0x28, ttl 52, id 103, offset 0, flags [DF], proto TCP (6), length 52)
    1.3.3.7.43542 > 192.168.0.2.55150: Flags [.], seq 1, ack 2, win 510, options [nop,nop,TS val 574500001 ecr 2610994962], length 0

I cant answer your question about the ACKs, however, `recv(1024, MSG_WAITALL)` will not exit until all 1024 bytes are received or the connection is disconnected. But your client is not sending 1024 bytes. You should not be using `MSG_WAITALL` in an echo server (which BTW is not echoing anything back to the client). Also, in your server loop, `s.close()` should be `client.close()` — Remy Lebeau, Jul 07 '22 at 19:38
@RemyLebeau hey Remy! Thank you for the answer. Yea, I do know about it, it's fine. I've asked about this here https://stackoverflow.com/questions/72890745/why-does-python-socket-recv-not-wait-for-the-full-message — Emilien Vidal, Jul 07 '22 at 19:47

Why does a simple TCP echo server produce two identical ACKs for one received byte?

0 Answers0