"TCP/IP detailed" reading notes

1 TCP/IP Overview 1.1 TCP/IP protocol

Generally speaking, the TCP/IP protocol refers to the "TCP/IP protocol family", which refers to the collection of network protocols including TCP, IP and other network protocols. The TCP/IP protocol can also be considered an implementation of the OSI model (but it has only four layers). The structure from bottom to top is shown in the following illustration.

Figure 1-1 TCP/IP protocol stack

The link layer is primarily responsible for the drive of the physical device.

Network layer main processing group (can be simply considered to be the transmission message segment) in the network activities. such as a grouped selection.

The transport layer provides end-to-end communication primarily for applications at both ends of the transmission.

the application layer is responsible for processing the data. 1.2 TCP/IP transmission process Overview

First, the Physical address (MAC address) of any host in the world is not the same. At the link layer, the data can be transmitted through this physical address. In fact, the LAN is directly relying on the MAC address for data transmission.

The internet is formed by the combination of thousands of internet LANs. LAN and LAN are connected by one or more routers. Its topological structure can be simply understood as the following diagram (which is certainly more complex than this). Links each router maintains a table of reasons. This routing table can be simply considered to have all subordinate direct host IP addresses and MAC addresses, plus a default table (can be multiple) pointing to the next routing device.

Figure 1-2 Internet topology map

1. Send data from BSDI to Sun

In fact, there is also a routing table on each host. On Windows we can view it through the route print command. When the BSDI IP layer receives the upper-level data, it first searches the local routing table. Discover the destination IP address 104.252.13.33 and itself on the same network (104.252.13.0). So BSDI issued an ARP broadcast, Sun received the broadcast after the discovery of its own IP and ARP packet query IP address exactly match, then postback a packet containing its own MAC address. With the destination MAC address, BSDI can send the packet to sun. In fact, there is an ARP cache in BSDI (that is, BSDI already knows the MAC address of the end). IP addresses are redundant for the transmission of data. The local area network is to rely on the MAC address communication.

2. Send data from BSDI to 192.48.96.9

You can see that this IP address 192.48.96.9 is not actually in any of the LAN in Figure 1-2. Instead, it exists in the extranet Internet.

Similarly, BSDI searches the native routing table and discovers that the IP Address table does not exist in its own routing table. The packet is then sent to the default table. The default table points to the Router sun (Sun is the host but also acts as a router role). Therefore, a physical layer packet with a destination IP address of 192.48.96.9 but a MAC address that is the Sun's Mac is constructed in the BSDI link layer. Because the MAC address is the root of the transmission, IP packets are sent to sun.

When Sun receives the message, it also traverses its own routing table and discovers that there is no corresponding table, and sends the IP packet to the router NetB corresponding to its default table. The difference here is that sun and NetB are connected through slip, and the packets from sun to NetB do not involve MAC addresses. Because the transmission between them is by the slip agreement. As can be seen from here, a packet from the source host to the destination host, the intermediate experience of the transmission protocol is diverse. However, the destination IP address remains unchanged.

NetB after the IP packet is received. Similarly, traversing its own routing table, it is still found that there is no matching table, so the IP packet is sent to the router gateway specified by the default table. Analogy

Suppose a node assumes that a 192.48.xx.xx table exists in the routing table. This class of routers will discover the IP packet's destination IP address 192.48.96.9 network number and the table destination network number is 192.48. The IP datagram is therefore sent to the router to which the table is directed. Suppose the IP address of the router is 192.48.1.5 (although it seems that the end of the general subnet should be 1), that is, router 3 in the following figure.

Access to the data can be found that the IP address can be divided into a, B, C, D, e five categories. As shown in the following figure.

Figure 1-3 IP Address sorting

192.48.1.5 is clearly a class B address. The Class B address network number is clearly indicated in the above figure. IP routing, in turn, requires matching network numbers. Is this network number this network number? Here by my repeated thinking research, "TCP/IP Detailed volume a" chapter III on this part of the description, the network number should actually be understood as "network number + host number in the subnet number."

Router 3 search its own routing table, found that there is no exactly match the table (network number + host number), but there is a network number matching the address 192.48.64.6 Router 4 (network number matching needs the subnet mask to participate), so the IP data packages to the Router 4. The network number matching process is as follows (assuming router 3 has a subnet mask of ffff40)

Router 4 also sends IP data packages to router 5 by matching the network number.

Router 5 searches its own routing table and finds that there is an exact match to the table. The IP packet is then sent to the B host with an IP address of 192.48.96.9. This data is transmitted correctly.

The matching path is shown in the following figure.

Figure 1-4 IP Packet Routing

Here are a few points to explain.

1, please do not link the routers here with the home router. Home routers are managed by private IP, and here is the IP is the public IP, I think the two types of IP is very different.

2,ip datagrams do not always exist in the network, the IP head has a eight-bit length TTL (lifetime), its general implementation is to pass a router minus 1, when it is a zero router discarded the IP packet.

2 IP protocol 2.1 IP message Format

IP protocol is the core of the entire TCP/IP.

The format of the IP datagram is shown in the following illustration

Figure 2-1 IP Datagram format

TOS is now ignored, but it must be 0 after 4 digits.

The 16-bit total length represents the length of the entire IP datagram.

The identity field identifies each datagram sent by the host. It usually adds 1 to each data sent. This is essentially a marker for each data IP message. After the IP packet is fragmented, the router or host can determine which IP packets belong to the IP fragment.

Because of the possibility of fragmentation in the composition of IP packet transmission, the 3-bit sign bit and slice offset are used in slicing and assembling.

The TTL indicates when the datagram can exist on the network. 2.2 Subnet mask

The subnet mask and IP address are "and" operations to derive the IP subnet. such as 140.252.4.5, the subnet mask is 255.255.255.0. Then do the "and" budget after the subnet is 140.152.4.0. This is how the router matches the network number of the routing table as described above.

3 UDP

Cond

4 TCP handshake, data transmission and wave 4.1 TCP message Format

The head of the TCP protocol is shown in the following illustration.

Figure 4-1 IP Datagram format

A 32-bit serial number, that is, the ISN number, indicating the number of the data being sent (pointing to the first data of the message). The isn number recorded while establishing the connection actually identifies the connection (the originating isn+ source IP and source mesh port, which actually uniquely identifies either connection). The data that is sent later is numbered from the start isn number. Theoretically this starting isn should be random, and any two times will not repeat, this is different from the ordinary random, so TCP has its own set of random algorithm, generally may be 0.5s plus 64000 or each build a connection plus 64000, about 9.5 hours after the round.

There are actually two problems here.

1, it is entirely possible that the isn number of a connection sending data is the same as the starting isn number of the next connection. However, with the IP header source IP and the TCP head source header port, two IP packets can be completely differentiated. (This simple question bothered me for a long time). The reason why TCP needs a random start isn is not to differentiate between a host and a host (in fact, they are naturally differentiated by source IP). It is to differentiate two hosts, and the source-mesh port has the same two consecutive connections. This prevents an IP datagram from being sent late, causing an incorrect explanation to the end (page 176th of TCP\IP).

In fact, the state of the end of TCP time_wait people who have a certain understanding will still be surprised: the 37th page of UNIX Network programming volume 1 clearly points out that Time_wait has two roles, one of which is "it allows old, repetitive sections to fade through the network." The random selection of the starting ISN number (hereinafter called the SYN Number), as described above, should be the same.

Here is the analysis: Assume that the isn number of the previous connection A is due to the transmission of the data from 0 to 11, and then the connection is interrupted. Immediately thereafter reconnect (assuming the connection is immediately attached), the connection is B (the AB connection will obviously not exist at the same time, two connections cannot be established with the same IP port). Suppose B has a SYN number of 10. A of the 11th message is delayed to send, but a connection has been closed (because received another resend 11th message and closed), it may be connected to B accept, this is obviously a mistake. What is the probability of this happening?

Suppose that AB establishes the interval between t,ab without any connection established, here according to Isn0.5s Plus 64000, to establish a connection plus 64000 algorithm, then AB's SYN exists the following relationship (assuming within the same 9.5h cycle)

syn_a+64000* (t/0.5+1) =syn_b (t>0)

The most extreme situation is that a at a certain speed (assuming v) to send data, while the B connection has been idle, then B has been expecting a syn_b+1 IP message. You need to meet the previous situation

Because the unit of ISN is byte, the time unit is wonderful, 128000byte/s count the beginning and end character of each byte, for 128m/bs. Requires 1280 trillion of speed. In fact, because of the existence of IP and TCP header, 128mb/s this rate is not enough. So this situation is almost impossible.

Things are getting more and more complicated, and we know that isn a certain time cycle, then in the next cycle it is possible to appear in the network two identical isn packets. Suppose a connection is built on a SYN number of isn0, 9.5h does not send data completely, sends data at the end of 9.5h and terminates the connection, assuming that one of the packets is isn0+64000+1 and is delayed. Immediately after the B connection establishes the SYN number, which is exactly isn0+64000, it sends a data immediately, then its first data byte isn number is isn0+64000+1. This is likely to cause misreading of the end. This condition requires a TCP connection to last longer than 9.5 hours, and is a small probability event. But small probability events can also occur.

Then the foolproof approach should be to try to avoid two data packets with the ISN number in the same network.

We know that there is a field TTL (Live time) in the IP header. That is, a message must have been discarded by the link after the TTL time has been issued. However, the theory should be the TTL parameter of time, it is difficult to achieve with "time", its general implementation is the TTL in each pass through a router minus 1, to 0 o'clock discarded. As a result, the lifetime of the message can only be estimated, the MSL (the longest time to survive) came into being, the parameter exists in the host system and is only an estimate of the true MSL. Because the time required for routers to forward IP messages and the time on the link are not accurately estimated, MSL cannot be accurately estimated. If TCP is actively terminating the connection at the end of the connection and is designed to be a time_wait state that lasts 2*MSL time, it can be inferred that the isn number can be repeated every 9.5 hours, as long as the actual MSL is less than the 9.5h,b connection at the A connection termination 2*MSL (2msl< 9.5) can be established, at this time, A's all IP packets must have gone. Assuming that sender a receives side B, the time of 2 *MSL is sufficient to ensure that the end-a-end receives the B-fin signal and then emits an ACK signal.

think carefully, with the time_wait, the random syn number seems redundant. Because it has been found from above that the repetition of isn is difficult to avoid completely. However, the MSL is generally designed to be 2min or 30s, and the previous analysis has clearly indicated that the MSL