Talk:Web Science/Part1: Foundations of the web/Transmission Control Protocol/Port numbers

Join the discussion: Ask and questions and provide answers

• If you click the ask a question button you're question will appear at the bottom of this list.
• If you click the give an answer you will be able to provide an answer to the questions that have been asked so far.

Source and destination address in TCP-header

In the video, it looks like TCP packets contain the destination IP-address as well as the port and the same for the source-address. My question would be: As the IP-header already contains the IP-addresses, isn't it a total redundancy to also put them into a TCP-header? I also don't see these two fields in the RFC793 header description. --Onse (discuss • contribs) 12:22, 1 November 2013 (UTC)

You are totally right. The video mixes up concepts of IP and TCP as we saw in the flipped classroom session of IP discussing NAT for many concepts on the internet we need to mix up protocols. So when defining a socket we need an IP address from the IP header and a port number from the TCP header. The video itself doesn't do the best job of clearly seperating those two concepts and I am looking forward for us to update the video at some point in time. --renepick (discuss) 16:19, 1 November 2013 (UTC)

He did not say TCP has IP address. He was talking about a concept which name is Socket. we call IP+Port a Socket .that is it. they are not related to each other. --141.26.69.70 (discuss) 14:14, 5 November 2016 (UTC)

Checksum in IP- and TCP-header

I asked myself, whether the checksums in TCP- and IP-packets are redundant. I knew that the IP-checksum is only calculated of the header. TCP calculates it of header and data and I believe even some information from the IP-packet (see pseudo header in RFC793). Therefore, I felt it would be better if IP would have been designed to calculate a checksum of header and data so that TCP would not have to. The only argument against it, that I could come up with, was that calculating checksums on every hop with data included would might have taken too long in 1981. --Onse (discuss • contribs) 12:39, 1 November 2013 (UTC)

I then found an answer to my question in the RFC791 which I wanted to share in case someone else was confused about this too. Quoting from that RFC: "This [IP] checksum at the internet level is intended to protect the internet header fields from transmission errors. There are some applications where a few data bit errors are acceptable while retransmission delays are not. If the internet protocol enforced data correctness such applications could not be supported.". But now a new question arises for me: If that was the intention, why didn't they just calculate two checksums (one of the header the other of data)? This way, IP packets could be dropped if the header-checksum did not match. But they could still be delivered with a mismatching data-checksum but correct header checksum. The destination-client could then decide for himself, if he wants to drop the packet or not. --Onse (discuss • contribs) 12:39, 1 November 2013 (UTC)

The portion of header in the whole package is small as compared to the portion of the data. Use-cases wherein only header is of interest are specific, but the imposed overhead of a second checksum would be generic. Overall package size and protocol efficiency would suffer. Therefore it is pragmatic to use 1 checksum for both and drop all on failure, imho. --Gluteus (discuss • contribs) 12:20, 5 November 2013 (UTC)