I am looking at an application which transmits precisely 4380 bytes over HTTP, including headers, before the connection stalls. 4380 happens to be exactly 3 times the maximum segment size of a 1500-byte Ethernet frame (1500 bytes minus 40 bytes of TCP/IP headers times 3).
The connection appears to remain open; it's just that no data is being received.
Why would it stall after precisely 3 ethernet frames? Where should I start looking for a reason?
Related
I am building an app where my phone frequently send data to my server. Since I would be using my mobile data, I was wondering how much data it cost to set up (and tear down?) a TCP connection to my server.
TCP Three-way handshake
Device 1 sends its TCP sequence number and maximum segment size to Device 2.
Device 2 responds by sending its sequence number and maximum segment size to Device 1.
Device 1 acknowledges receipt of the sequence number and segment size information.
Each packet is composed of an IP header and data (payload). In this case, the data section contains TCP. The TCP header contains various fields including the source and destination ports, sequence and acknowledgment numbers, window size, TCP flags, urgent pointer, and reserved bits.
Like the IP header, the TCP header may also contain options. (Note that TCP options and IP options are two different things.) Because the TCP options change the length of the TCP header, the length is set in the header.
IPv4 header is five 4-byte chunks, or 20 bytes total.
TCP typically usually uses 24 bytes of the header for handshake (first two packets) and about 20 for normal packet transmission.
Maximum Segment Size (MSS): 4 bytes
Window Scale (WSCALE): 3 bytes
Timestamp (TS): 10 bytes
No Operation (NOP): 1 byte
Selective Acknowledgment Permitted (SackOK): 2 bytes
Selective Acknowledgment Data: 10 bytes (plus 8 bytes for each additional pair of sequence numbers)
Terminating a Connection
Even though establishing a connection using 3-way handshake requires only 3 packets to be transmitted, tearing down one requires 4!
In the first frame the client sends a FIN that is accompanied by an ACK. The FIN parameter is set, it will inform the server that it has no more data to send.
The response (2nd frame) would be simply the server acknowledging the FIN sent from the client.
Even though TCP has established connections between the two computers, the connections are still independent of one another. Therefore, the server will also transmit a FIN to the client.
You guessed it right ... the client would ACK the FIN of the server in the last forth packet.
The offset of each of the frames is typically 20 bytes.
To sum it up.
Establishing a connection: ~ 128-136 bytes
Tearing down a connection: ~ 160 bytes
If you plan to use TLS / SSL handshake, this is estimated to be between 4.5k-6.5k.
Note: Please also take a look at TCP/IP Header Compression
Sources:
Inside the TCP Handshake
Explanation of the Three-Way Handshake via TCP/IP
Studying Normal Traffic, Part Three: TCP Headers | Symantec Connect
Suppose I have 2 Mbps line is equal to 2,000,000 bits per second.
Which is equal to 250,000 bytes per second. Which is equal to 250 bytes per millisecond. That means we can only send/receive message of size 250 bytes per millisecond. What will happened if send/receive more than 1 packet of 250 bytes per milisecond.
If a sender attempts to send data at a higher rate than the network can support, initially the data will be buffered - in the network card, operating systems buffers, and/or buffers in the sending process. Eventually the buffers will fill, and the sending thread or process will be blocked until buffers are emptied.
If buffers on routers or the receiving system are filled, packets are dropped.
Maximum Ethernet packet sizes have been about 1500 bytes until Gigabit Ethernet came along. With higher speeds, jumbo frames were implemented which increased packet sizes to about 9k bytes.
TCP RFC mentions that the receiver should send an ACK for every 2 full size segment it receives (assuming they are inorder) and should not delay an ACK.
Considering the window size is 8 segments and sender sends 8 full segments, does this mean, the receiver sends 4 ACKs even though it has received 8 segments?
Can it not acknowledge all 8 segments with one ACK?
Ill just copy paste the important Part of the RFC right in here:
4.2.3.2 When to Send an ACK Segment
A host that is receiving a stream of TCP data segments can
increase efficiency in both the Internet and the hosts by
sending fewer than one ACK (acknowledgment) segment per data
segment received; this is known as a "delayed ACK" [TCP:5].
A TCP SHOULD implement a delayed ACK, but an ACK should not
be excessively delayed; in particular, the delay MUST be
less than 0.5 seconds, and in a stream of full-sized
segments there SHOULD be an ACK for at least every second
segment.
The Full RFC can be found here: RFC 1122
My application connects to the server using TCP and system is working fine. Using Wireshark I noticed that some TCP packets of 60 bytes are sent with no data. Is this normal?
as part of TCP transmissions and handshake are there some packets sent with no data?
Thanks
Kumar
There are the ACK packets that carry no data and only acknowledge received data. When using Wireshark it should display these "flags" on the empty packets.
To be more accurate you should show a screenshot of the wireshark capture, so we know what the size you mean is.
Meanwhile I dissected an ACK packet of IPv4 TCP traffic here and these are my results:
Protocol Size Description
Ethernet protocol 14 byte 2 MAC adresses (6 byte), Protocoll type (2 byte)
Internet protocol 20 byte The default header size
TC protocol 32 byte The default header size (20 byte) + options (12 byte)
_____________________________________________________________________________________
Total 66 byte
without EP 52 byte (Probably the size the OP is talking about)
without EP, Opts 40 byte (The size talked about in the comments)
The options in my case were 2 NOPs (each 1 byte) and two timestamps (each 5 byte??). The order of the protocols is the same as in Wireshark.
Wireshark splits the information down to each field, so you can see what takes up how much space.
When the server sends 4 or more - 25 Byte packets to the client only the first 2 are processed by the client. I am using Event select on the client, and send on the server. There are no errors but only the first 2 packets are displayed. Thanks in advance.
Without looking at your code I can only think of one issue that you might be overlooking,
Maybe you are missing a point that TCP is a stream based protocol. If you send data by calling Send function 10 times from client then it is not necessary that you have to call the receive function 10 times on receiving side. All data maybe retrieved in 1 receive or 5 or 8 or 12 receives. I mean don't try to look at it in form of packets. You have to do Framing yourself to identify the packets.
When you send 4 packets of 25 byte each. The total is 100 byte data.
On receiving side you may be getting 2 packets of 50 bytes and you have to identify your packets yourself by using some start and end markers etc...
You can also get a single packet of 100 bytes or 10 packets of 10 bytes. keep that in mind.