TOR cell size is 512 bytes but most TOR packets have size of 586
bytes. My question is that why there is such difference in size (74 bytes difference)?
The 586-byte packet being referenced in the papers is Tor's 512-byte cell wrapped in the headers of three different protocols: TLS, TCP, IP.
In my set up, using Wireshark, I'm seeing lots of outgoing packets with an overall length of 609 bytes. (This is equivalent to your 597 bytes.) This is the "on the wire" size, meaning it also takes into account the Ethernet frame header (which is 14 bytes).
Looking inside the frame, I have the following, in bytes:
Ethernet size 609 (including header, 14 bytes)
IP size 595 (including header, 20 bytes)
TCP size 575 (including header, 32 bytes)
Data size 543
The size of my 595-byte IP packet is the equivalent to the 586-byte packet referenced in the documents - their number doesn't include the Ethernet header (I think). The difference between these two sizes could be accounted for by noting that TCP and IP headers can vary in size, depending on the type of traffic, what options are used in the headers, and any padding. (I don't have a solid answer for this part - someone else might know better. This could also be where variable-length Tor cells come into play.)
In my own testing, instead of TOR packets with size of 586 bytes,
there are packets with size of 543 bytes in TOR traffic and packets
with size of 565 bytes in Obfsproxy traffic.
Once the Ethernet, IP and TCP headers are stripped off, we're left with the "data". This is Tor's 512-byte cell together with TLS Application Data, which is used to make Tor traffic look like HTTPS traffic. (This is basically the TLS header and encryption, on which there's a brief discussion in this ticket). On my set up I'm also seeing 543 bytes for the size of this data.
The greater size of data in the Obfsproxy case can probably be explained by padding of some sort.
Relating to above question, there are lots of packets with size of
1460 bytes in backward direction (from server to client). So what
happens to the fixed cell size?
The lower-level protocols don't care what data is in the layers above them. They just get passed the data and package it up themselves. Tor's cell size doesn't come into play as this isn't what gets put on the wire.
The data in the outgoing packets will likely be HTTP requests, which are small and will fit into a single Tor cell. Bundle this up with the required headers, and you still have quite a small (i.e. 586/609-byte) packet. This will all fit into a single Ethernet frame, which is what gets sent.
The data in the incoming packets will likely be much larger - e.g. the data associated with a webpage, a file, etc. This data won't fit into a single Tor cell, and has to be split across several. The data from several of these cells can themselves be bundled into a single Ethernet frame. On my set up I'm seeing 1506-byte Ethernet frames (presumably the MTU), which stripped of the Ethernet/IP/TCP headers gives 1440 bytes of data. In this 1440 bytes there is the TLS layer data together with the Tor data. (Where the Tor data is likely two complete cells together with a fragment.)
In my own testing on TOR traffic, from 9939 packets that were sent
from client to server, there were 2648 packets with different sizes
than 543, like 126,1086,1629,4101,612 and so on.
These are probably fragmentation artefacts, or the ends of particular streams of data. Those that are greater than ~1500 bytes are probably Ethernet jumbo frames. They may also contain parts of different TCP streams combined into the same Ethernet frame (Wireshark should be able to show you this). Either way, the same general point applies: the idea of Tor's cells have been abstracted away by the point the data is put on the line in the form of Ethernet frames.
