TCP/IP Illustrated, Volume 1: The Protocols, 2nd Edition

TCP/IP Illustrated, Volume 1: The Protocols, 2nd Edition

English | 2011 | ISBN: 978-0321336316 | 1059 Pages | PDF, EPUB | 31 MB


TCP/IP Illustrated, Volume 1, Second Edition, is a detailed and visual guide to today’s TCP/IP protocol suite. Fully updated for the newest innovations, it demonstrates each protocol in action through realistic examples from modern Linux, Windows, and Mac OS environments. There’s no better way to discover why TCP/IP works as it does, how it reacts to common conditions, and how to apply it in your own applications and networks.
Building on the late W. Richard Stevens’ classic first edition, author Kevin R. Fall adds his cutting-edge experience as a leader in TCP/IP protocol research, updating the book to fully reflect the latest protocols and best practices. He first introduces TCP/IP’s core goals and architectural concepts, showing how they can robustly connect diverse networks and support multiple services running concurrently. Next, he carefully explains Internet addressing in both IPv4 and IPv6 networks. Then, he walks through TCP/IP’s structure and function from the bottom up: from link layer protocols–such as Ethernet and Wi-Fi–through network, transport, and application layers.
Fall thoroughly introduces ARP, DHCP, NAT, firewalls, ICMPv4/ICMPv6, broadcasting, multicasting, UDP, DNS, and much more. He offers extensive coverage of reliable transport and TCP, including connection management, timeout, retransmission, interactive data flow, and congestion control. Finally, he introduces the basics of security and cryptography, and illuminates the crucial modern protocols for protecting security and privacy, including EAP, IPsec, TLS, DNSSEC, and DKIM. Whatever your TCP/IP experience, this book will help you gain a deeper, more intuitive understanding of the entire protocol suite so you can build better applications and run more reliable, efficient networks.

+

The idea of different instantiations of the same connection becomes clear when we recall that a TCP connection is identified by a pair of endpoints, creating a 4-tuple of two address/port pairs. If a connection had one of its segments delayed for a long period of time and closed, but then opened again with the same 4-tuple, it is conceivable that the delayed segment could reenter the new connection’s data stream as valid data. This would be most troublesome. By taking steps to avoid overlap in sequence numbers between connection instantiations, we can try to minimize this risk. It does suggest, however, that an application with a very great need for data integrity should employ its own CRCs or checksums at the application layer to ensure that its own data has been transferred without error. This is generally good practice in any case, and it is commonly done for large files.

This is a clear indication that the connection has terminated, but it is not entirely accurate. It was really the sender that terminated the connection, but it did so based on the lack of response from the receiver.

Apart from the use of keepalive segments, there are some other interesting features of this connection we will mention briefly. First, the server uses DSACKs (see Chapter 14). Each ACK contains the sequence number range of the previously received in-window segment. Next, a small bit of data is exchanged at time 26.09. The data represents a single key press. It is sent to the server, ACKed by the server, and echoed back. The data is encrypted, causing the packets containing data to be 48 bytes in user data size.

Interestingly, the echoed character is sent twice. We can see that packet 11, which contains the echoed character is not ACKed immediately. Recall from Chapter 14 that Linux uses an RTO of at least 200ms. Here we see that the Linux server retransmits the echoed character 200ms later, which produces an immediate response from the client. Because this test was performed on an uncongested LAN, it is highly unlikely that segment 11 was dropped. Instead, it appears that Linux produced a spurious retransmission due to the client delaying ACKs. This is a similar sort of hazard we saw when exploring the poor interaction between the Nagle algorithm and delayed ACKs we discussed in Chapter 15. Here, the dynamic results in an unnecessary delay of about 200ms.