Analysing a HTTP request with tcpdump

Question

I am trying to understand the acks from the sequence numbers in a TCP/IP packet. AFAIK, an ack from a transmitted package is calculated by the following [1]. In [2] I have an HTTP request to a site.

1. Lets look tho the TCP handshake. We can see that the ack from the SYN packet sent by the client is 934031638 (934031637+0+1). But then the client sent an ack to the server with the value 1? Shouldn't it be 934031639?
2. After the handshake, the client requests the site with seq 1:205 and the ack 1. Why the seq uses the value 1:205 and not just 205? And why the request has the ack value if it is the first request to start to fetch the site?
3. Then the reply has the ack 205 and not 206. Why is this happening?
4. If we look the part that terminates the communication, the client sends 2 FIN requests with the seq 205 and 1242. Why is it necessary to send 2 FIN requests and not just 1?

[1] ack=seq from the sender + length of the packet + 1.

[2] 13:38:34.092700 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [S], seq 934031637, win 29200, options [mss 1460,sackOK,TS val 68040338 ecr 0,nop,wscale 7], length 0 13:38:34.097142 IP 10.152.138.125.8080 > 10.0.2.15.49288: Flags [S.], seq 2912700929, ack 934031638, win 65535, options [mss 1460], length 0 13:38:34.097175 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [.], ack 1, win 29200, length 0 13:38:34.097685 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [P.], seq 1:205, ack 1, win 29200, length 204: HTTP: GET http://www.site.com/ HTTP/1.1 13:38:34.098435 IP 10.152.138.125.8080 > 10.0.2.15.49288: Flags [.], ack 205, win 65535, length 0 13:38:34.377601 IP 10.152.138.125.8080 > 10.0.2.15.49288: Flags [P.], seq 1:1242, ack 205, win 65535, length 1241: HTTP: HTTP/1.1 200 OK 13:38:34.377631 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [.], ack 1242, win 31025, length 0 13:38:34.379531 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [F.], seq 205, ack 1242, win 31025, length 0 13:38:34.379755 IP 10.152.138.125.8080 > 10.0.2.15.49288: Flags [.], ack 206, win 65535, length 0 13:38:34.381469 IP 10.152.138.125.8080 > 10.0.2.15.49288: Flags [F.], seq 1242, ack 206, win 65535, length 0 13:38:34.381494 IP 10.0.2.15.49288 > 10.152.138.125.8080: Flags [.], ack 1243, win 31025, length 0

Answer 1

But then the client sent an ack to the server with the value 1? Shouldn't it be 934031639?

Your output shows relative instead of absolute sequence numbers. To get the absolute numbers use the appropriate option. From the documentation:

-S
--absolute-tcp-sequence-numbers
     Print absolute, rather than relative, TCP sequence numbers.

... with seq 1:205 and the ack 1. Why the seq uses the value 1:205 and not just 205?

Because it is easier to understand the output then, i.e. one sees that this packet continues after (relative) sequence number 1 and goes to 205, i.e. length 204.

Then the reply has the ack 205 and not 206.

Because it the ACK to the FIN which be definition should be the last sequence from the data plus one to distinguish it from an ACK to the last data.

If we look the part that terminates the communication, the client sends 2 FIN requests with the seq 205 and 1242. Why is it necessary to send 2 FIN requests and not just 1?

There are not two FIN from the client. There is one FIN from the client to the server at port 8080 and one from the server on port 8080 to the client. Both FIN have the expected sequence number for the direction of the traffic. Perfectly normal.