1

I was somehow convinced that the TCP checksum was a header checksum (similar to the IP checksum), but I'm now having doubts reading the Wikipedia article:

The checksum field is the 16 bit one's complement of the one's complement sum of all 16-bit words in the header and text.

This seems a little crazy to me that the TCP checksum, which is placed in the header (as opposed to a footer), depends upon bytes sent after the header. This is a hindrance to hardware optimised TCP. Essentially, this nullifies "cut-through" architectures that would start sending the TCP header before knowing the text of the TCP packet.

Why is the TCP checksum placed in the header when it depends on the text? Can this be mitigated for "cut-through" architectures?

Randomblue
  • 1,165
  • 5
  • 16
  • 33
  • I think you'll find that building something that modifies the TCP payload without first having the entire packet will be nearly impossible anyway. There are complications because a "unit" of data that you're modifying can be split across packets. The optimization that this prevents is almost never possible anyway. – David Schwartz Dec 04 '12 at 20:00
  • Are you talking about IP fragmentation? All my TCP packets are in one IP packet. – Randomblue Dec 04 '12 at 20:41
  • No, I'm talking about TCP segmentation. For example, to change "FOO" to "BAR", you have to consider the fact that the "F" might be the last byte of data in the packet and the next packet may start with "OO". – David Schwartz Dec 04 '12 at 20:44
  • Hum. I'm working with the FIX protocol, and the payload is quite small (~200 bytes), so it all fits in one TCP packet without any problem. – Randomblue Dec 04 '12 at 20:46
  • The issue has nothing to do with whether or not it fits. Just because the data can fit in one packet doesn't mean it will be sent in one packet. TCP makes no guarantees about segmentation. – David Schwartz Dec 04 '12 at 20:47
  • Well in my case it turns out that there is no TCP fragmentation or IP fragmentation. Good thinking though. – Randomblue Dec 04 '12 at 20:48
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/6618/discussion-between-david-schwartz-and-justin) – David Schwartz Dec 04 '12 at 20:49

2 Answers2

4

Yes, the checksum is in the TCP header. Rather than check wiki you can go to the references here: RFC 793 Specifically read section 3 paragraph 1.

When you mention cut-through I assume referring to switching. The switch isn't changing anything in the packet payload so there would be no need to recompute the checksum.

Nathan V
  • 711
  • 5
  • 16
  • Well actually I'm trying to build an application in the spirit of a cut-through switch that would modify the payload a little. This is annoying. – Randomblue Dec 04 '12 at 11:24
  • 8
    It's there to prevent you from doing what you want to do. :) – Nathan V Dec 04 '12 at 11:33
  • @Randomblue you can send a TCP checksum of 0 and put your own checksum at the end of the payload that is crafted in such a way that the initially sent TCP checksum is correct. – haslersn Sep 28 '21 at 07:34
0

I think you could start with scapy to do packet manipulation in real time.

Mircea Vutcovici
  • 17,619
  • 4
  • 56
  • 83