Understanding IP, TCP, and HTTP
1–10 of 62 posts
Re: Understanding IP, TCP, and HTTP
#2Re: Understanding IP, TCP, and HTTP
#3Without guarantee of completeness, to avoid the spread of misinformation:
- IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has to send a packet that doesn't fit through the path MTU.
- The end points use Packet Too big ICMP6 messages to determine _path_ MTU, which is different from just "the MTU".
- With IPv4, the sender chooses whether a router will fragment when the packet exceeds the next-hop MTU or whether the router should drop the packet and send a Fragmentation Needed ICMP message - where the latter again is used for path MTU discovery.
- Path MTU discovery is useful because it allows the sending IP implementation to push the chunking higher up the stack when the sending higher-level protocol has the capability (as is the case with TCP, but not with UDP, for example), which tends to produce lower overhead. Unfortunately, some clueless firewall administrators, such as those responsible for AWS EC2, do filter all ICMP because they for unknown reasons consider it to be bad, thus breaking PMTUD, which can lead to hanging TCP connections.
- TCP sequence numbers are for bytes, always, with the special case of SYN and FIN also counting as "bytes" in the sequence, but never for segments.
Re: Understanding IP, TCP, and HTTP
#4How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread of misinformation: - IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has t…
Re: Understanding IP, TCP, and HTTP
#5Re: Understanding IP, TCP, and HTTP
#6It's nice to see this recent increased emphasis on Web/mobile developers understanding the technologies that link it all together. The next thing I would add is a high level overview of the sockets API. While these topics aren't critical to most day-to-day lives of developers, they are certainly useful to understand.
Talk about understanding the sockets API ;-) here's the content section for chapter 5:
5.1. getaddrinfo() — Prepare to launch!
5.2. socket() — Get the File Descriptor!
5.3. bind() — What port am I on?
5.4. connect() — Hey, you!
5.5. listen() — Will somebody please call me?Re: Understanding IP, TCP, and HTTP
#7How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread of misinformation: - IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has t…
Just out of curiosity, what do you do? Is this knowledge germane to where you work? I've just recently become interested in this stuff, so I'm curious to get a lay of the land.
As for getting an understanding of how TCP/IP works, I think Stevens' classic TCP/IP Illustrated still is a good book to get started, even if somewhat dated in some details (no IPv6, in particular), but the general principles still apply. Though maybe there are newer equally good books around that I just don't know about?
Re: Understanding IP, TCP, and HTTP
#8How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread of misinformation: - IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has t…
I'll give them the benefit of the doubt and say he got his terms wrong. The IPv6 RFC states that IPv6 requires a minimum MTU of 1280 bytes. I guess that's what he meant.
https://www.ietf.org/rfc/rfc2460.txt
Packet Size Issues
IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece, link-specific fragmentation and reassembly must be provided at a layer below IPv6.
Re: Understanding IP, TCP, and HTTP
#9How I love it when people without deep knowledge of some subject write authoritative sounding articles. Without guarantee of completeness, to avoid the spread of misinformation: - IPv6 fragmentation has nothing to do with some "minimum payload size" (whatever that is) - there simply is no fragmentation being done by routers, the sender still can fragment however it pleases, and presumably will do so whenever it has t…
> "minimum payload size" (whatever that is) I'll give them the benefit of the doubt and say he got his terms wrong. The IPv6 RFC states that IPv6 requires a minimum MTU of 1280 bytes. I guess that's what he meant. https://www.ietf.org/rfc/rfc2460.txt Packet Size Issues IPv6 requires that every link in the internet have an MTU of 1280 octets or greater. On any link that cannot convey a 1280-octet packet in one piece,…
Re: Understanding IP, TCP, and HTTP
#10It's nice to see this recent increased emphasis on Web/mobile developers understanding the technologies that link it all together. The next thing I would add is a high level overview of the sockets API. While these topics aren't critical to most day-to-day lives of developers, they are certainly useful to understand.
This is a very readable online book on networking and sockets: http://beej.us/guide/bgnet/output/html/multipage/index.html Talk about understanding the sockets API ;-) here's the content section for chapter 5: 5.1. getaddrinfo() — Prepare to launch! 5.2. socket() — Get the File Descriptor! 5.3. bind() — What port am I on? 5.4. connect() — Hey, you! 5.5. listen() — Will somebody please call me?