This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
1962-1968: Packet-switching networks developed1969: Birth of Internet1971: People communicate over a network1972: Computers can connect more freely and easily1973: Global Networking becomes a reality1974: Packets become mode of transfer1976: Networking comes to many1977: E-mail takes off, Internet becomes a reality1979: News Groups born1981: Things start to come together
1982: TCP/IP defines future communication1983: Internet gets bigger1984: Growth of Internet Continues1986: Power of Internet Realised1987: Commercialisation of Internet Born1989: Large growth in Internet1990: Expansion of Internet continues1991: Modernisation Begins1992: Multimedia changes the face of the Internet1993: The WWW Revolution truly begins1994: Commercialisation begins1995: Commercialisation continues apace1996: Microsoft enters
[1] R. Zakon. Hobbes’ Internet Timeline. RFC 2235 (Informational). Internet Engineer-ing Task Force, Nov. 1997.
Meanwhile what’s happening in China?
1.3 The InternetWhat’s The Internet?What pops up in your mind if I say “Internet”?
For me, the answer is...
and...
TCP/IP[1] Wikipedia.Google—Wikipedia, The Free Encyclopedia. [Online; accessed 11-March-
2015]. 2015.[2] Wikipedia. Internet protocol suite — Wikipedia, The Free Encyclopedia. [Online;
[1] T.J. Socolofsky and C.J. Kale. TCP/IP tutorial. RFC 1180 (Informational). InternetEngineering Task Force, Jan. 1991.
[2] Wikipedia. Internet protocol suite — Wikipedia, The Free Encyclopedia. [Online;accessed 21-February-2015]. 2015.
What’s TCP/IP?A set of protocols designed for the InternetProtocol — a rule, a treaty, an agreement ...
message that is transmitted to, and received by, all students who are not sleeping).You raise your hand (transmitting an implicit message to the teacher). Your teacheracknowledges you with a smile, saying “Yes . . .” (a transmitted message encourag-ing you to ask your question—teachers love to be asked questions), and you then askyour question (that is, transmit your message to your teacher). Your teacher hearsyour question (receives your question message) and answers (transmits a reply toyou). Once again, we see that the transmission and receipt of messages, and a set ofconventional actions taken when these messages are sent and received, are at theheart of this question-and-answer protocol.
Network Protocols
A network protocol is similar to a human protocol, except that the entities exchang-ing messages and taking actions are hardware or software components of somedevice (for example, computer, smartphone, tablet, router, or other network-capable
8 CHAPTER 1 • COMPUTER NETWORKS AND THE INTERNET
GET http://www.awl.com/kurose-ross
TCP connection request
Time Time
TCP connection reply
<file>
Hi
Got the time?
Time Time
Hi
2:00
Figure 1.2 � A human protocol and a computer network protocol
TCP/IP Protocol StackEvery networked computer has it inside
See also: [10, Sec. 1.3.5, The Relationship of Services to Protocols]
11
2.3 Network Architecture
Network architecture
Architecture: A big blueprint without worrying about any design details.
• A set of layers and protocols
• Neither the details of the implementation nor the specification of the interfacesis part of the architecture.
Services
Interfaces between layers (primitives, functions)
Q1. Who provides which service to whom?
Q2. How this service is implemented?
Protocols
• for peer to peer talking
• The internal implementation of services provided by a layer
• It’s common that different hosts use different implementations of the same pro-tocols (e.g. Linux vs. Windows)
• Protocol changes have no effects on it’s upper/lower layers
Layered Design ExampleTaking an airplane trip
source host to destination host in the Internet. But this is not quite the analogy weare after. We are looking for some structure in Figure 1.21. Looking at Figure 1.21,we note that there is a ticketing function at each end; there is also a baggage func-tion for already-ticketed passengers, and a gate function for already-ticketed andalready-baggage-checked passengers. For passengers who have made it through thegate (that is, passengers who are already ticketed, baggage-checked, and through thegate), there is a takeoff and landing function, and while in flight, there is an airplane-routing function. This suggests that we can look at the functionality in Figure 1.21in a horizontal manner, as shown in Figure 1.22.
Figure 1.22 has divided the airline functionality into layers, providing a frame-work in which we can discuss airline travel. Note that each layer, combined with the
Figure 1-14. The philosopher-translator-secretary architecture.
units, packets, prepending a layer 3 header to each packet. In this example, M is
split into two parts, M 1 and M 2 , that will be transmitted separately.
Layer 3 decides which of the outgoing lines to use and passes the packets to
layer 2. Layer 2 adds to each piece not only a header but also a trailer, and gives
the resulting unit to layer 1 for physical transmission. At the receiving machine
the message moves upward, from layer to layer, with headers being stripped off as
it progresses. None of the headers for layers below n are passed up to layer n.
The important thing to understand about Fig. 1-15 is the relation between the
virtual and actual communication and the difference between protocols and inter-
faces. The peer processes in layer 4, for example, conceptually think of their
communication as being ‘‘horizontal,’’ using the layer 4 protocol. Each one is
likely to have procedures called something like SendToOtherSide and GetFrom-
OtherSide, even though these procedures actually communicate with lower layers
across the 3/4 interface, and not with the other side.
Each protocol is completely independent of the other ones
13
2.4 TCP/IP Overview
For example
• The translators (L2) can switch from Dutch to Finnish without touching L1 or L3
• The secretaries (L1) can switch from email to telephone without disturbing (or eveninforming) the other layers
An analogymay help explain the idea ofmultilayer communication. Imagine two philoso-phers (peer processes in layer 3), one of whom speaks Urdu and English and one of whomspeaks Chinese and French. Since they have no common language, they each engage atranslator (peer processes at layer 2), each of whom in turn contacts a secretary (peerprocesses in layer 1). Philosopher 1 wishes to convey his affection for oryctolagus cunicu-lus to his peer. To do so, he passes a message (in English) across the 2/3 interface to histranslator, saying “I like rabbits,” as illustrated in Fig. 29. The translators have agreed ona neutral language known to both of them, Dutch, so the message is converted to “Ik vindkonijnen leuk.” The choice of the language is the layer 2 protocol and is up to the layer 2peer processes.[10, Sec. 1.3, Network Software, p. 31]The translator then gives the message to a secretary for transmission, for example,
by email (the layer 1 protocol). When the message arrives at the other secretary, it ispassed to the local translator, who translates it into French and passes it across the 2/3interface to the second philosopher. Note that each protocol is completely independentof the other ones as long as the interfaces are not changed. The translators can switchfrom Dutch to, say, Finnish, at will, provided that they both agree and neither changes hisinterface with either layer 1 or layer 3. Similarly, the secretaries can switch from email totelephone without disturbing (or even informing) the other layers. Each process may addsome information intended only for its peer. This information is not passed up to the layerabove.
2.4 TCP/IP Overview
Historical
The ARPANET was a research network sponsored by the DoD (U.S. Department ofDefense). ... When satellite and radio networks were added later, the existing pro-tocols had trouble interworking with them, so a new reference architecture wasneeded. Thus, from nearly the beginning, the ability to connect multiple networksin a seamless way was one of the major design goals. This architecture later be-came known as the TCP/IP Reference Model, after its two primary protocols. [10,Sec. 1.4.2, The TCP/IP Reference Model]Given the DoD’s worry that some of its precious hosts, routers, and internetworkgateways might get blown to pieces at a moment’s notice by an attack from theSoviet Union, another major goal was that the network be able to survive loss ofsubnet hardware, without existing conversations being broken off. In other words,the DoD wanted connections to remain intact as long as the source and destinationmachines were functioning, even if some of the machines or transmission lines inbetween were suddenly put out of operation. Furthermore, since applications withdivergent requirements were envisioned, ranging from transferring files to real-timespeech transmission, a flexible architecture was needed.
TCP/IP OverviewBasic Structure
14
2.5 Terminology
----------------------------
| network applications |
| |
|... \ | / .. \ | / ...|
| ----- ----- |
| |TCP| |UDP| |
| ----- ----- |
| \ / |
| -------- |
| | IP | |
| ----- -*------ |
| |ARP| | |
| ----- | |
| \ | |
| ------ |
| |ENET| |
| ---@-- |
----------|-----------------
|
----------------------o---------
Ethernet Cable
1. Where will an incoming Ethernet frame go?ARP: 0x0806IP: 0x0800
2. Where will an incoming IP packet go?TCP: 0x06UDP: 0x11
3. Where will an incoming transport message (UDPdatagram, TCP segment) go?
[1] J. Postel and J.K. Reynolds. Standard for the transmission of IP datagrams over IEEE802 networks. RFC 1042 (INTERNET STANDARD). Internet Engineering Task Force,Feb. 1988.
[2] Wikipedia. Carrier sense multiple access with collision detection — Wikipedia, TheFree Encyclopedia. [Online; accessed 11-March-2015]. 2015.
Sender IP Address 223.1.2.2Sender Enet Address 08-00-28-00-38-A9Target IP Address 223.1.2.1Target Enet Address 08-00-39-00-2F-C3
The updated table
IP address Ethernet address223.1.2.1 08-00-39-00-2F-C3223.1.2.2 08-00-28-00-38-A9223.1.2.3 08-00-5A-21-A7-22223.1.2.4 08-00-10-99-AC-54
ARP References
[1] D. Plummer. Ethernet Address Resolution Protocol: Or Converting Network ProtocolAddresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware. RFC826 (INTERNET STANDARD). Updated by RFCs 5227, 5494. Internet EngineeringTask Force, Nov. 1982.
• Subtract 2? All “0”s and all “1”s. (this is the old story)
Subnet Calculatorsubnetcalc — a free IP subnet calculatorTry:
∼$ subnetcalc 202.203.132.244/26
22
2.10 CIDR
Subnetting References
[1] T. Pummill and B. Manning. Variable Length Subnet Table For IPv4. RFC 1878 (His-toric). Internet Engineering Task Force, Dec. 1995.
[2] Y. Rekhter et al. Address Allocation for Private Internets. RFC 1918 (Best CurrentPractice). Updated by RFC 6761. Internet Engineering Task Force, Feb. 1996.
CIDR An IP addressing scheme that replaces the older system based on classes A, B andC.
Why CIDR?With a new network being connected to the Internet every 30 minutes the Internet was
faced with two critical problems:
• Running out of IP addresses
• Running out of capacity in the global routing tables
Running out of IP addressesUsing the old addressing scheme, the Internet could support:
• 126 Class A networks that could include up to 16,777,214 hosts each
• Plus 65,000 Class B networks that could include up to 65,534 hosts each
• Plus over 2 million Class C networks that could include up to 254 hosts each
only 3% of the assigned addresses were actually being used.
Global Routing Tables At Capacity
• As the number of networks on the Internet increased, so did the number of routes.
• A few years back it was forecasted that the global backbone Internet routers werefast approaching their limit on the number of routes they could support.
• Even using the latest router technology, the maximum theoretical routing table sizeis approximately 60,000 routing table entries.
• If nothing was done the global routing tables would have reached capacity by mid-1994 and all Internet growth would be halted.
How Were These Problems Solved?Two solutions were developed and adopted by the global Internet community:
• Restructuring IP address assignments to increase efficiency
• Hierarchical routing aggregation to minimize route table entries
Restructuring IP Address AssignmentsInstead of being limited to network identifiers (or ”prefixes”) of 8, 16 or 24 bits, CIDRcurrently uses prefixes anywhere from 13 to 27 bits.
/27 1/8 of a Class C 32 hosts/26 1/4 of a Class C 64 hosts/25 1/2 of a Class C 128 hosts/24 1 Class C 256 hosts/16 256 Class C 65,536 hosts
(= 1 Class B)/13 2,408 Class C 524,288 hosts
Hierarchical Routing Aggregation To Minimize Routing Table Entries
Route Aggregation a single high-level route entry can representmany lower-level routesin the global routing tables. Similar to the telephone network.
User Impacts
• The Internet is currently a mixture of both ”CIDR-ized” addresses and old Class A, Band C addresses.
• Almost all new routers support CIDR and the Internet authorities strongly encourageall users to implement the CIDR addressing scheme.
CIDR References
[1] V. Fuller and T. Li. Classless Inter-domain Routing (CIDR): The Internet AddressAssignment and Aggregation Plan. RFC 4632 (Best Current Practice). Internet En-gineering Task Force, Aug. 2006.
• a packet sent to an anycast address is routed to the ”nearest” interface having thataddress
• is allocated from the unicast address space
27
2.12 NAT & Packet Filtering
IPv6 References
[1] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. RFC2460 (Draft Standard). Updated by RFCs 5095, 5722, 5871, 6437, 6564, 6935, 6946,7045, 7112. Internet Engineering Task Force, Dec. 1998.
[2] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. RFC 4291 (DraftStandard). Updated by RFCs 5952, 6052, 7136, 7346, 7371. Internet EngineeringTask Force, Feb. 2006.
[5] Wikipedia. IPv6—Wikipedia, The Free Encyclopedia. [Online; accessed 21-February-2015]. 2015.
2.12 NAT & Packet Filtering
Network Address Translation (NAT)
40.30.20.10
192.168.1.1
192.168.1.4
192.168.1.3
192.168.1.2
Internet12.13.14.15
Src IP Src Port NAT Router IP Port192.168.1.2 3456 12.13.14.15 1192.168.1.3 6789 12.13.14.15 2192.168.1.3 8910 12.13.14.15 3192.168.1.4 3750 12.13.14.15 4
[1] K. Egevang and P. Francis. The IP Network Address Translator (NAT). RFC 1631 (In-formational). Obsoleted by RFC 3022. Internet Engineering Task Force, May 1994.
[2] Jeff Tyson. How Network Address Translation Works — HowStuffWorks.com. [On-line; accessed 26 March 2015]. Feb. 2, 2001.
A packet filter is a piece of software which looks at the header of packets as they passthrough, and decides the fate of the entire packet. It might decide to
• DROP the packet (i.e., discard the packet as if it had never received it),• ACCEPT the packet (i.e., let the packet go through), or• something more complicated.
Why need transport layer if its service is so similar to the network layer service?The answer is subtle, but crucial. The transport code runs entirely on the users’machines, but the network layer mostly runs on the routers, which are operated bythe carrier (at least for a wide area network). [10, Sec. 6.1.1, Services provided tothe upper layers]
• What happens if the network layer offers inadequate service?
• What if it frequently loses packets?
• What happens if routers crash from time to time?
Problems occur, that’s what. The users have no real control over the network layer,so they cannot solve the problem of poor service by using better routers or puttingmore error handling in the data link layer because they don’t own the routers. Theonly possibility is to put on top of the network layer another layer that improves thequality of the service.If all real networks were flawless and all had the same service primitives and wereguaranteed never, ever to change, the transport layer might not be needed.
TCP is optimized for accurate delivery rather than timely delivery
TCP is optimized for accurate delivery rather than timely delivery, and therefore,TCP sometimes incurs relatively long delays (on the order of seconds) while waitingfor out-of-order messages or retransmissions of lost messages. It is not particularlysuitable for real-time applications such as Voice over IP. For such applications, pro-tocols like the Real-time Transport Protocol (RTP) running over the User DatagramProtocol (UDP) are usually recommended instead. [11, Sec. 2, Network Function]
The reliability and flow control mechanisms described above require that TCPs ini-tialize and maintain certain status information for each data stream. The combina-tion of this information, including sockets, sequence numbers, and window sizes,is called a connection. Each connection is uniquely specified by a pair of socketsidentifying its two sides. [8, Sec 1.5, RFC 793]
Destination port (16 bits) identifies the receiving port
Sequence number (32 bits) has a dual role:
• If the SYN flag is set (1), then this is the initial sequence number. The sequencenumber of the actual first data byte and the acknowledged number in the corre-sponding ACK are then this sequence number plus 1.
• If the SYN flag is clear (0), then this is the accumulated sequence number of thefirst data byte of this segment for the current session.
Sequence numbers allow receivers to discard duplicate packets and properly se-quence reordered packets.
Acknowledgment number (32 bits) if the ACK flag is set then the value of this field isthe next sequence number that the receiver is expecting. This acknowledges receiptof all prior bytes (if any). The first ACK sent by each end acknowledges the otherend’s initial sequence number itself, but no data.Acknowledgments allow senders to determine when to retransmit lost packets.
Data offset (4 bits) specifies the size of the TCP header in 32-bit words. The minimumsize header is 5 words and the maximum is 15 words thus giving the minimum sizeof 20 bytes and maximum of 60 bytes, allowing for up to 40 bytes of options in theheader. This field gets its name from the fact that it is also the offset from the startof the TCP segment to the actual data.
Reserved (3 bits) for future use and should be set to zero
Flags (9 bits) (aka Control bits) contains 9 1-bit flags
• NS (1 bit) – ECN-nonce concealment protection (experimental: see RFC 3540).• CWR (1 bit) – Congestion Window Reduced (CWR) flag is set by the sendinghost to indicate that it received a TCP segment with the ECE flag set and hadresponded in congestion control mechanism (added to header by RFC 3168).
• ECE (1 bit) – ECN-Echo has a dual role, depending on the value of the SYN flag.It indicates:– If the SYN flag is set (1), that the TCP peer is ECN capable.– If the SYN flag is clear (0), that a packet with Congestion Experienced flagin IP header set is received during normal transmission (added to header byRFC 3168).
• URG (1 bit) – indicates that the Urgent pointer field is significant• ACK (1 bit) – indicates that the Acknowledgment field is significant. All packetsafter the initial SYN packet sent by the client should have this flag set.
• PSH (1 bit) – Push function. Asks to push the buffered data to the receivingapplication. (See [1, Sec. 4.2.2.2, RFC 1122] for more details)
• RST (1 bit) – Reset the connection• SYN (1 bit) – Synchronize sequence numbers. Only the first packet sent fromeach end should have this flag set. Some other flags and fields change meaningbased on this flag, and some are only valid for when it is set, and others when itis clear.
36
3.1 TCP
• FIN (1 bit) – No more data from sender
Window size (16 bits) the size of the receive window, which specifies the number ofwindow size units (by default, bytes) (beyond the sequence number in the acknowl-edgment field) that the sender of this segment is currently willing to receive (see also[11, Sec. 4.4.3, Flow control] and [11, Sec. 4.7, Window Scaling])
Checksum (16 bits) The 16-bit checksum field is used for error-checking of the headerand data
Urgent pointer (16 bits) if the URG flag is set, then this 16-bit field is an offset from thesequence number indicating the last urgent data byte
Options (Variable 0–320 bits, divisible by 32) The length of this field is determined bythe data offset field. Options have up to three fields: Option-Kind (1 byte), Option-Length (1 byte), Option-Data (variable). The Option-Kind field indicates the type ofoption, and is the only field that is not optional. Depending on what kind of option weare dealing with, the next two fields may be set: the Option-Length field indicates thetotal length of the option, and the Option-Data field contains the value of the option,if applicable. For example, an Option-Kind byte of 0x01 indicates that this is a No-Opoption used only for padding, and does not have an Option-Length or Option-Data bytefollowing it. An Option-Kind byte of 0 is the End Of Options option, and is also onlyone byte. An Option-Kind byte of 0x02 indicates that this is the Maximum SegmentSize option, and will be followed by a byte specifying the length of the MSS field(should be 0x04). Note that this length is the total length of the given options field,including Option-Kind and Option-Length bytes. So while the MSS value is typicallyexpressed in two bytes, the length of the field will be 4 bytes (+2 bytes of kind andlength). In short, an MSS option field with a value of 0x05B4 will show up as (0x02 0x040x05B4) in the TCP options section.Some options may only be sent when SYN is set; they are indicated below as [SYN].Option-Kind and standard lengths given as (Option-Kind,Option-Length).
• 0 (8 bits) – End of options list• 1 (8 bits) – No operation (NOP, Padding) This may be used to align option fieldson 32-bit boundaries for better performance.
• 2,4,SS (32 bits) – Maximum segment size (see maximum segment size) [SYN]• 3,3,S (24 bits) – Window scale (see window scaling for details) [SYN][4, Sec. 2.2,RFC 1323]
• 4,2 (16 bits) – Selective Acknowledgement permitted. [SYN] (See selective ac-knowledgments for details)[6, Sec. 2, RFC 2018]
• 5,N,BBBB,EEEE,... (variable bits, N is either 10, 18, 26, or 34)- Selective AC-Knowledgement (SACK)[6, Sec. 3,RFC 2018] These first two bytes are followedby a list of 1–4 blocks being selectively acknowledged, specified as 32-bit be-gin/end pointers.
• 8,10,TTTT,EEEE (80 bits)- Timestamp and echo of previous timestamp (see TCPtimestamps for details)[4, Sec. 3.2,RFC 1323](The remaining options are historical, obsolete, experimental, not yet standard-ized, or unassigned)
Padding The TCP header padding is used to ensure that the TCP header ends and databegins on a 32 bit boundary. The padding is composed of zeros.[8, Sec. 3.1, RFC 793]
37
3.1 TCP
[1] D. Borman. TCP Options and Maximum Segment Size (MSS). RFC 6691 (Informa-tional). Internet Engineering Task Force, July 2012.
[2] J. Postel. The TCP Maximum Segment Size and Related Topics. RFC 879. Updatedby RFC 6691. Internet Engineering Task Force, Nov. 1983.
Establishing a TCP ConnectionSEC. 6.5 THE INTERNET TRANSPORT PROTOCOLS: TCP 561
Tim
e
Host 1 Host 2
SYN (SEQ = y, ACK = x + 1)
SYN (SEQ = x)
(SEQ = x + 1, ACK = y + 1)
Host 1 Host 2
SYN (SEQ = y, ACK = x + 1)
SYN (SEQ = x)
SYN (SEQ = y)
SYN (SEQ = x , ACK = y + 1)
(a) (b)
Figure 6-37. (a) TCP connection establishment in the normal case. (b) Simul-
taneous connection establishment on both sides.
In the event that two hosts simultaneously attempt to establish a connection
between the same two sockets, the sequence of events is as illustrated in Fig. 6-
37(b). The result of these events is that just one connection is established, not
two, because connections are identified by their end points. If the first setup re-
sults in a connection identified by (x, y) and the second one does too, only one
table entry is made, namely, for (x, y).
Recall that the initial sequence number chosen by each host should cycle
slowly, rather than be a constant such as 0. This rule is to protect against delayed
duplicate packets, as we discussed in Sec 6.2.2. Originally this was accomplished
with a clock-based scheme in which the clock ticked every 4 µsec.
However, a vulnerability with implementing the three-way handshake is that
the listening process must remember its sequence number as soon it responds with
its own SYN segment. This means that a malicious sender can tie up resources on
a host by sending a stream of SYN segments and never following through to com-
plete the connection. This attack is called a SYN flood, and it crippled many
Web servers in the 1990s.
One way to defend against this attack is to use SYN cookies. Instead of
remembering the sequence number, a host chooses a cryptographically generated
sequence number, puts it on the outgoing segment, and forgets it. If the three-way
handshake completes, this sequence number (plus 1) will be returned to the host.
It can then regenerate the correct sequence number by running the same crypto-
graphic function, as long as the inputs to that function are known, for example, the
other host’s IP address and port, and a local secret. This procedure allows the host
to check that an acknowledged sequence number is correct without having to
To establish a connection, TCP uses a three-way handshake. Before a client attemptsto connect with a server, the server must first bind to and listen at a port to open it upfor connections: this is called a passive open. Once the passive open is established, aclient may initiate an active open. To establish a connection, the three-way (or 3-step)handshake occurs [11, Sec. 4.1, Connection establishment]:
1. SYN: The active open is performed by the client sending a SYN to the server. The clientsets the segment’s sequence number to a random value A.
2. SYN-ACK: In response, the server replies with a SYN-ACK. The acknowledgment numberis set to one more than the received sequence number i.e. A+1, and the sequencenumber that the server chooses for the packet is another random number, B.
3. ACK: Finally, the client sends an ACK back to the server. The sequence number is setto the received acknowledgement value i.e. A+1, and the acknowledgement numberis set to one more than the received sequence number i.e. B+1.
At this point, both the client and server have received an acknowledgment of the con-nection. The steps 1, 2 establish the connection parameter (sequence number) for onedirection and it is acknowledged. The steps 2, 3 establish the connection parameter (se-quence number) for the other direction and it is acknowledged. With these, a full-duplexcommunication is established.
The connection termination phase uses a four-way handshake, with each side of theconnection terminating independently. When an endpoint wishes to stop its half of theconnection, it transmits a FIN packet, which the other end acknowledges with an ACK.Therefore, a typical tear-down requires a pair of FIN and ACK segments from each TCPendpoint. After both FIN/ACK exchanges are concluded, the side that sent the first FINbefore receiving one waits for a timeout before finally closing the connection, during whichtime the local port is unavailable for new connections; this prevents confusion due todelayed packets being delivered during subsequent connections. [11, Sec. 4.2, Connectiontermination]A connection can be ”half-open”, in which case one side has terminated its end, but
the other has not. The side that has terminated can no longer send any data into theconnection, but the other side can. The terminating side should continue reading the datauntil the other side terminates as well.It is also possible to terminate the connection by a 3-way handshake, when host A sends
a FIN and host B replies with a FIN & ACK (merely combines 2 steps into one) and host Areplies with an ACK. This is perhaps the most common method.Some host TCP stacks may implement a half-duplex close sequence, as Linux or HP-UX
do. If such a host actively closes a connection but still has not read all the incoming datathe stack already received from the link, this host sends a RST instead of a FIN (Section4.2.2.13 in [1, RFC 1122]). This allows a TCP application to be sure the remote applicationhas read all the data the former sent—waiting the FIN from the remote side, when itactively closes the connection. But the remote TCP stack cannot distinguish between aConnection Aborting RST and Data Loss RST. Both cause the remote stack to lose all thedata received.tcpdump output∼$ tcpdump -S -i lo
12:47:09.106903 IP localhost.37831 > localhost.3333:
12:47:26.963264 IP localhost.37831 > localhost.3333:
Flags [.], ack 2476477988, win 257, ..., length 0
39
3.1 TCP
State Transition Diagram
CLOSED
LISTEN
SYN_RCVD SYN_SENT
ESTABLISHED
FIN_WAIT_1
CLOSE_WAIT
FIN_WAIT_2
CLOSING
TIME_WAIT
LAST_ACK
data transfer state
starting point
2MSL timeout
passive open
active open
simultaneous close
appl: passive open
send: <nothing> appl: active open
send: SYN
appl: send data
send: SYNrecv
: SYN;
send: S
YN, ACK
recv: R
ST
timeoutsend: RST
recv: SYN
send: SYN, ACKsimultaneous open
recv
: SYN
, ACK
send: A
CK
appl: closesend: FIN
recv: ACKsend: <nothing>
recv: FIN
send: ACK
recv: ACKsend: <nothing>
recv: FIN, A
CK
send: ACK
recv: ACK
send: <nothing>
appl:
close
send: F
IN
recv: FIN
send: ACK
recv: FIN
send: ACK
appl: closesend: FIN
appl: close
or timeout
recv: ACK
send: <nothing>
active close
passive close
normal transitions for clientnormal transitions for server
appl: state transitions taken when application issues operationrecv: state transitions taken when segment receivedsend: what is sent for this transition
TCP state transition diagram.
Reprinted from TCP/IP Illustrated, Volume 2: The Implementationby Gary R. Wright and W. Richard Stevens,
[11, Sec. 4, Protocol operation] TCP protocol operations may be divided into threephases. Connections must be properly established in a multi-step handshake process (con-nection establishment) before entering the data transfer phase. After data transmission
40
3.1 TCP
is completed, the connection termination closes established virtual circuits and releasesall allocated resources.A TCP connection is managed by an operating system through a programming interface
that represents the local end-point for communications, the Internet socket. During thelifetime of a TCP connection the local end-point undergoes a series of state changes:[8,Sec. 3.2, RFC 793]
LISTEN (server) represents waiting for a connection request from any remote TCP andport.
SYN-SENT (client) represents waiting for a matching connection request after havingsent a connection request.
SYN-RECEIVED (server) represents waiting for a confirming connection request acknowl-edgment after having both received and sent a connection request.
ESTABLISHED (both server and client) represents an open connection, data receivedcan be delivered to the user. The normal state for the data transfer phase of theconnection.
FIN-WAIT-1 (both server and client) represents waiting for a connection termination re-quest from the remote TCP, or an acknowledgment of the connection terminationrequest previously sent.
FIN-WAIT-2 (both server and client) represents waiting for a connection termination re-quest from the remote TCP.
CLOSE-WAIT (both server and client) represents waiting for a connection terminationrequest from the local user.
CLOSING (both server and client) represents waiting for a connection termination re-quest acknowledgment from the remote TCP.
LAST-ACK (both server and client) represents waiting for an acknowledgment of the con-nection termination request previously sent to the remote TCP (which includes anacknowledgment of its connection termination request).
TIME-WAIT (either server or client) represents waiting for enough time to pass to be surethe remote TCP received the acknowledgment of its connection termination request.[According to RFC 793 a connection can stay in TIME-WAIT for a maximum of fourminutes known as a MSL (maximum segment lifetime).]
CLOSED (both server and client) represents no connection state at all.
netstat
∼$ netstat -nta
∼$ netstat -ntap
∼$ netstat -ntape
∼$ netstat -ntap | grep ESTAB
∼$ netstat -nlp | grep :80
∼$ netstat -nr
∼$ netstat -ie
∼$ man netstat
41
3.1 TCP
Sliding Window
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Send first 8 segments
Receive first 3 acknowledgements
Send next 3 segments
The sliding window serves several purposes:
• it guarantees the reliable delivery of data
• it ensures that the data is delivered in order
• it enforces flow control between the sender and the receiver.
SEC. 6.5 THE INTERNET TRANSPORT PROTOCOLS: TCP 565
client’s acknowledgement shows up, the server releases the connection and
deletes the connection record.
6.5.8 TCP Sliding Window
As mentioned earlier, window management in TCP decouples the issues of
acknowledgement of the correct receipt of segments and receiver buffer alloca-
tion. For example, suppose the receiver has a 4096-byte buffer, as shown in
Fig. 6-40. If the sender transmits a 2048-byte segment that is correctly received,
the receiver will acknowledge the segment. However, since it now has only 2048
bytes of buffer space (until the application removes some data from the buffer), it
will advertise a window of 2048 starting at the next byte expected.
Applicationdoes a 2-KBwrite
Applicationdoes a 2-KBwrite
Applicationreads 2 KB
Sender isblocked
Sender maysend up to 2-KB
Receiver’sbuffer
0 4 KB
2 KB
2 KB
Empty
Full
2 KB SEQ = 0
2 KB SEQ = 2048
1 KB SEQ = 4096
ACK = 2048 WIN = 2048
ACK = 4096 WIN = 0
ACK = 4096 WIN = 2048
2 KB1 KB
Sender Receiver
Figure 6-40. Window management in TCP.
Now the sender transmits another 2048 bytes, which are acknowledged, but
the advertised window is of size 0. The sender must stop until the application
Packet Lost?Go-Back-N
42
3.1 TCP
these unnecessary retransmissions. Imagine, in our message-dictation scenario, thatif every time a word was garbled, the surrounding 1,000 words (for example, a win-dow size of 1,000 words) had to be repeated. The dictation would be slowed by allof the reiterated words.
As the name suggests, selective-repeat protocols avoid unnecessary retransmis-sions by having the sender retransmit only those packets that it suspects werereceived in error (that is, were lost or corrupted) at the receiver. This individual, as-needed, retransmission will require that the receiver individually acknowledge cor-rectly received packets. A window size of N will again be used to limit the number
224 CHAPTER 3 • TRANSPORT LAYER
Sender Receiver
send pkt0
send pkt1
send pkt2
send pkt3
(wait)
rcv ACK0
send pkt4
rcv ACK1
send pkt5
send pkt2
send pkt3
send pkt4
send pkt5
pkt2 timeout
rcv pkt0
send ACK0
rcv pkt1
send ACK1
rcv pkt3, discard
send ACK1
rcv pkt4, discard
send ACK1
rcv pkt5, discard
send ACK1
rcv pkt2, deliver
send ACK2
rcv pkt3, deliver
send ACK3
X(loss)
Figure 3.22 � Go-Back-N in operation
Figure 3.1 shows the operation of the GBNprotocol for the case of a window size of fourpackets. Because of this window size limita-tion, the sender sends packets 0 through 3but then must wait for one or more of thesepackets to be acknowledged before proceed-ing. As each successive ACK (for example,ACK0 and ACK1) is received, the windowslides forward and the sender can transmitone new packet (pkt4 and pkt5, respectively).On the receiver side, packet 2 is lost and thuspackets 3, 4, and 5 are found to be out oforder and are discarded. [5, Sec. 3.4.3, Go-Back-N (GBN), P.223]
Cumulative Acknowledgment
[11, Sec. 4.4.1, Reliable Transmission] TCP primarily uses a cumulative acknowl-edgment scheme, where the receiver sends an acknowledgment signifying that thereceiver has received all data preceding the acknowledged sequence number. Thesender sets the sequence number field to the sequence number of the first payloadbyte in the segment’s data field, and the receiver sends an acknowledgment speci-fying the sequence number of the next byte they expect to receive. For example, ifa sending computer sends a packet containing four payload bytes with a sequencenumber field of 100, then the sequence numbers of the four payload bytes are 100,101, 102 and 103. When this packet arrives at the receiving computer, it would sendback an acknowledgment number of 104 since that is the sequence number of thenext byte it expects to receive in the next packet.Relying purely on the cumulative acknowledgment scheme employed by the originalTCP protocol can lead to inefficiencies when packets are lost. For example, suppose10,000 bytes are sent in 10 different TCP packets, and the first packet is lost duringtransmission. In a pure cumulative acknowledgment protocol, the receiver cannotsay that it received bytes 1,000 to 9,999 successfully, but failed to receive the firstpacket, containing bytes 0 to 999. Thus the sender may then have to resend all10,000 bytes. [11, Sec. 4.6, Selective Acknowledgments]
ACK lost?
43
3.1 TCP
244 CHAPTER 3 • TRANSPORT LAYER
then the ACK is acknowledging one or more previously unacknowledged segments.Thus the sender updates its SendBase variable; it also restarts the timer if there cur-rently are any not-yet-acknowledged segments.
A Few Interesting Scenarios
We have just described a highly simplified version of how TCP provides reliabledata transfer. But even this highly simplified version has many subtleties. To get agood feeling for how this protocol works, let’s now walk through a few simplescenarios. Figure 3.34 depicts the first scenario, in which Host A sends one seg-ment to Host B. Suppose that this segment has sequence number 92 and contains 8bytes of data. After sending this segment, Host A waits for a segment from B withacknowledgment number 100. Although the segment from A is received at B, theacknowledgment from B to A gets lost. In this case, the timeout event occurs, andHost A retransmits the same segment. Of course, when Host B receives theretransmission, it observes from the sequence number that the segment containsdata that has already been received. Thus, TCP in Host B will discard the bytes inthe retransmitted segment.
Time Time
Host A Host B
Timeout
Seq=92, 8 bytes data
Seq=92, 8 bytes data
ACK=100
ACK=100
X(loss)
Figure 3.34 � Retransmission due to a lost acknowledgment
246 CHAPTER 3 • TRANSPORT LAYER
Doubling the Timeout Interval
We now discuss a few modifications that most TCP implementations employ. Thefirst concerns the length of the timeout interval after a timer expiration. In this mod-ification, whenever the timeout event occurs, TCP retransmits the not-yet-acknowledged segment with the smallest sequence number, as described above. Buteach time TCP retransmits, it sets the next timeout interval to twice the previousvalue, rather than deriving it from the last EstimatedRTT and DevRTT (asdescribed in Section 3.5.3). For example, suppose TimeoutInterval associatedwith the oldest not yet acknowledged segment is .75 sec when the timer first expires.TCP will then retransmit this segment and set the new expiration time to 1.5 sec. Ifthe timer expires again 1.5 sec later, TCP will again retransmit this segment, nowsetting the expiration time to 3.0 sec. Thus the intervals grow exponentially aftereach retransmission. However, whenever the timer is started after either of the twoother events (that is, data received from application above, and ACK received), the
Time Time
Host A Host B
Seq=92 timeout interval
Seq=92, 8 bytes data
Seq=100, 20 bytes data
ACK=100
ACK=120
X(loss)
Figure 3.36 � A cumulative acknowledgment avoids retransmission of thefirst segment
Selective-repeat
of outstanding, unacknowledged packets in the pipeline. However, unlike GBN, thesender will have already received ACKs for some of the packets in the window.Figure 3.23 shows the SR sender’s view of the sequence number space. Figure 3.24details the various actions taken by the SR sender.
The SR receiver will acknowledge a correctly received packet whether or not itis in order. Out-of-order packets are buffered until any missing packets (that is,packets with lower sequence numbers) are received, at which point a batch of pack-ets can be delivered in order to the upper layer. Figure 3.25 itemizes the variousactions taken by the SR receiver. Figure 3.26 shows an example of SR operation inthe presence of lost packets. Note that in Figure 3.26, the receiver initially bufferspackets 3, 4, and 5, and delivers them together with packet 2 to the upper layer whenpacket 2 is finally received.
It is important to note that in Step 2 in Figure 3.25, the receiver reacknowledges(rather than ignores) already received packets with certain sequence numbers belowthe current window base. You should convince yourself that this reacknowledgmentis indeed needed. Given the sender and receiver sequence number spaces in Figure3.23, for example, if there is no ACK for packet send_base propagating from thereceiver to the sender, the sender will eventually retransmit packet send_base,even though it is clear (to us, not the sender!) that the receiver has already received
3.4 • PRINCIPLES OF RELIABLE DATA TRANSFER 225
send_base nextseqnum
Window sizeN
Key:
Key:
AlreadyACK’d
Sent, notyet ACK’d
Usable,not yet sent
Not usable
Out of order(buffered) butalready ACK’d
Expected, notyet received
Acceptable(withinwindow)
Not usable
a. Sender view of sequence numbers
b. Receiver view of sequence numbers
rcv_base
Window sizeN
Figure 3.23 � Selective-repeat (SR) sender and receiver views ofsequence-number spaceThe SR receiver will acknowledge a correctly received packet whether or not it is in
order. Out-of-order packets are buffered until any missing packets (that is, packets withlower sequence numbers) are received, at which point a batch of packets can be deliveredin order to the upper layer. [5, Sec. 3.4.4, Selective Repeat (SR), p. 225]
44
3.2 UDP
The lack of synchronization between sender and receiver windows has impor-tant consequences when we are faced with the reality of a finite range of sequencenumbers. Consider what could happen, for example, with a finite range of four packetsequence numbers, 0, 1, 2, 3, and a window size of three. Suppose packets 0 through2 are transmitted and correctly received and acknowledged at the receiver. At thispoint, the receiver’s window is over the fourth, fifth, and sixth packets, which havesequence numbers 3, 0, and 1, respectively. Now consider two scenarios. In the firstscenario, shown in Figure 3.27(a), the ACKs for the first three packets are lost and
pkt0 rcvd, delivered, ACK0 sent
0 1 2 3 4 5 6 7 8 9
pkt1 rcvd, delivered, ACK1 sent
0 1 2 3 4 5 6 7 8 9
pkt3 rcvd, buffered, ACK3 sent
0 1 2 3 4 5 6 7 8 9
pkt4 rcvd, buffered, ACK4 sent
0 1 2 3 4 5 6 7 8 9
pkt5 rcvd; buffered, ACK5 sent
0 1 2 3 4 5 6 7 8 9
pkt2 rcvd, pkt2,pkt3,pkt4,pkt5delivered, ACK2 sent
0 1 2 3 4 5 6 7 8 9
pkt0 sent
0 1 2 3 4 5 6 7 8 9
pkt1 sent
0 1 2 3 4 5 6 7 8 9
pkt2 sent
0 1 2 3 4 5 6 7 8 9
pkt3 sent, window full
0 1 2 3 4 5 6 7 8 9
ACK0 rcvd, pkt4 sent
0 1 2 3 4 5 6 7 8 9
ACK1 rcvd, pkt5 sent
0 1 2 3 4 5 6 7 8 9
pkt2 TIMEOUT, pkt2resent
0 1 2 3 4 5 6 7 8 9
ACK3 rcvd, nothing sent
0 1 2 3 4 5 6 7 8 9
X(loss)
Sender Receiver
Figure 3.26 � SR operation
3.4 • PRINCIPLES OF RELIABLE DATA TRANSFER 227
3.2 UDPUDP Datagram
0 7 8 15 16 23 24 31+--------+--------+--------+--------+| Source | Destination || Port | Port |+--------+--------+--------+--------+| | || Length | Checksum |+--------+--------+--------+--------+|| data octets ...+---------------- ...
45
3.3 Socket Programming
Why need checksum?
See also [5, Sec. 3.3.2, UDP Checksum].
1. (layer 2) there is no guarantee that all the links between source and destinationprovide error checking;
2. (layer 3) even if segments are correctly transferred across a link, it’s possi-ble that bit errors could be introduced when a segment is stored in a router’smemory.
TCP/UDP References
[1] J. Postel. Transmission Control Protocol. RFC 793 (INTERNET STANDARD). Up-dated by RFCs 1122, 3168, 6093, 6528. Internet Engineering Task Force, Sept. 1981.
[2] J. Postel. User Datagram Protocol. RFC 768 (INTERNET STANDARD). Internet En-gineering Task Force, Aug. 1980.
1. puts the received message data into modifiedMessage
2. puts the source address (IP, Port) into serverAddress
• 2048: buffer size
UDPServer.py
1 from socket import *2 serverPort = 120003 serverSocket = socket(AF_INET, SOCK_DGRAM)4 serverSocket.bind(('', serverPort))5 print "The server is ready to receive"6 while 1:7 message, clientAddress = serverSocket.recvfrom(2048)8 modifiedMessage = message.upper()9 serverSocket.sendto(modifiedMessage, clientAddress)
serverSocket.bind(('', serverPort))
• explicitly assigns 12000 to the server’s socket
3.3.2 TCP
Two Sockets at the Server
into but also receives bytes from its socket; similarly, the server process not onlyreceives bytes from but also sends bytes into its connection socket.
We use the same simple client-server application to demonstrate socket program-ming with TCP: The client sends one line of data to the server, the server capitalizesthe line and sends it back to the client. Figure 2.30 highlights the main socket-relatedactivity of the client and server that communicate over the TCP transport service.
TCPClient.py
Here is the code for the client side of the application:
164 CHAPTER 2 • APPLICATION LAYER
Client process Server process
Clientsocket
Welcomingsocket
Three-way handshake
Connectionsocket
bytesbytes
Figure 2.29 � The TCPServer process has two sockets
• connect(): initiate the TCP connection (3-way handshake)
• send(): send out sentence through the client’s socket. No destination address needsto be specified
TCPServer.py
1 from socket import *2 serverPort = 120003 serverSocket = socket(AF_INET,SOCK_STREAM)4 serverSocket.bind(('',serverPort))5 serverSocket.listen(1)6 print 'The server is ready to receive'7 while 1:8 connectionSocket, addr = serverSocket.accept()9 sentence = connectionSocket.recv(1024)
• A connection-establishment request is nothing more than a TCP segment withdestination port number 12000 and a special connection-establishment bit setin the TCP header (discussed in Section 3.5[5]). The segment also includes asource port number that was chosen by the client.
• When the host operating system of the computer running the server process re-ceives the incoming connection-request segment with destination port 12000,it locates the server process that is waiting to accept a connection on port num-ber 12000. The server process then creates a new socket:
connectionSocket, addr = serverSocket.accept()
• Also, the transport layer at the server notes the following four values in theconnection-request segment: (1) the source port number in the segment, (2) theIP address of the source host, (3) the destination port number in the segment,and (4) its own IP address. The newly created connection socket is identifiedby these four values; all subsequently arriving segments whose source port,source IP address, destination port, and destination IP address match thesefour values will be demultiplexed to this socket. With the TCP connection nowin place, the client and server can now send data to each other.
Socket References
[1] B. Hall. Beej’s Guide to Network Programming: Using Internet Sockets. 2012.[2] Wikipedia. Network socket — Wikipedia, The Free Encyclopedia. [Online; accessed
eBay, since Susan has visited that site in the past. As Susan continues to browse theAmazon site, each time she requests a Web page, her browser consults her cookiefile, extracts her identification number for this site, and puts a cookie header linethat includes the identification number in the HTTP request. Specifically, each ofher HTTP requests to the Amazon server includes the header line:
Cookie: 1678
2.2 • THE WEB AND HTTP 109
Client host Server host
usual http request msg
usual http
response
Set-cookie
: 1678
usual http request msg
cookie: 1678
usual http
response
msg
usual http request msg
cookie: 1678
usual http
response
msg
Time
One week later
ebay: 8734
Server createsID 1678 for user
Time
Cookie file
Key:
amazon: 1678ebay: 8734
amazon: 1678ebay: 8734
Cookie-specificaction
access
access
entry in backenddatabase
Cookie-specificaction
Figure 2.10 � Keeping user state with cookiesSee also [5, Sec. 2.2.4, User-Server Interaction: Cookies]
HTTP/2Quoted from http://http2.github.io/faq/
• is binary, instead of textual
• is fully multiplexed, instead of ordered and blocking
• can therefore use one connection for parallelism
• uses header compression to reduce overhead
• allows servers to “push”responses proactively into client caches
[1] R. Fielding, Y. Lafon, and J. Reschke.Hypertext Transfer Protocol (HTTP/1.1): RangeRequests. RFC 7233 (Proposed Standard). Internet Engineering Task Force, June2014.
[2] R. Fielding, M. Nottingham, and J. Reschke.Hypertext Transfer Protocol (HTTP/1.1):Caching. RFC 7234 (Proposed Standard). Internet Engineering Task Force, June2014.
[3] R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Authentication.RFC 7235 (Proposed Standard). Internet Engineering Task Force, June 2014.
[4] R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Conditional Re-quests. RFC 7232 (Proposed Standard). Internet Engineering Task Force, June 2014.
[5] R. Fielding and J. Reschke.Hypertext Transfer Protocol (HTTP/1.1): Message Syntaxand Routing. RFC 7230 (Proposed Standard). Internet Engineering Task Force, June2014.
[6] R. Fielding and J. Reschke. Hypertext Transfer Protocol (HTTP/1.1): Semantics andContent. RFC 7231 (Proposed Standard). Internet Engineering Task Force, June2014.
[7] R. Fielding et al. Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Stan-dard). Obsoleted by RFCs 7230, 7231, 7232, 7233, 7234, 7235, updated by RFCs2817, 5785, 6266, 6585. Internet Engineering Task Force, June 1999.
[8] Wikipedia.HTML—Wikipedia, The Free Encyclopedia. [Online; accessed 21-February-2015]. 2015.
All hosts connected to the Internet should use DNSThe old host table system is inadequate for the global Internet for two reasons:
1. inability to scale
2. lack of an automated update process.
Old storyPrior to adopting DNS, the Network Information Center (NIC) maintained a large tableof Internet hosts called the NIC host table. Hosts included in the table were called regis-tered hosts, and the NIC placed hostnames and addresses into this file for all sites on theInternet.
Domain Name System
• Scales well
– Doesn’t rely on a single large table– Distributed database system that doesn’t bog down as the database grows
DNS currently provides information on approximately 16,000,000 hosts, while lessthan 10,000 are listed in the host table.
• Guarantees that new host information will be disseminated to the rest of the networkas it is needed
DNS softwares
DNSresolver
DNSserver
DNS query
DNS response
The resolver asks the questions.
The name server answers the questions.
With DNS, information is automatically disseminated, and only to those who areinterested.
• If a DNS server receives a request for information about a host for which it has noinformation, it passes on the request to an authoritative server.
An authoritative server is any server responsible for maintaining accurate infor-mation about the domain being queried.
56
4.2 DNS
• When the authoritative server answers, the local server saves (caches) the answerfor future use.
• The next time the local server receives a request for this information, it answers therequest itself.
Resource RecordsWhat’s associated with a domain name?Type Meaning ValueA IP address of a host 32-bit integerNS Name Server Name of a server for this domainMX Mail eXchange Priority, domain willing to accept emailHINFO Host INFOrmation CPU and OS in ASCIICNAME Canonical NAME Domain namePTR PoinTeR Alias for an IP address
When a resolver gives a domain name to DNS, what it gets back are the resourcerecords associated with that name.
Resource Records Examplewx672@cs2:~$ host -a mirrors.ustc.edu.cn
Dr. WhoeverDepartment of Unknown,University of Whatever,London, SE18 3ABUK
Dear Dr. Whoever,
As any dedicated reader can clearly see, the Ideal of practical reason is a rep-resentation of, as far as I know, the things in themselves; as I have shown else-where, the phenomena should only be used as a canon for our understanding.The paralogisms of practical reason are what first give rise to the architectonicof practical reason. As will easily be shown in the next section, reason wouldthereby be made to contradict, in view of these considerations, the Ideal of prac-tical reason, yet the manifold depends on the phenomena. Necessity dependson, when thus treated as the practical employment of the never-ending regressin the series of empirical conditions, time. Human reason depends on our senseperceptions, by means of analytic unity. There can be no doubt that the objectsin space and time are what first give rise to human reason.
Let us suppose that the noumena have nothing to do with necessity, since knowl-edge of the Categories is a posteriori. Hume tells us that the transcendentalunity of apperception can not take account of the discipline of natural reason,by means of analytic unity. As is proven in the ontological manuals, it is ob-vious that the transcendental unity of apperception proves the validity of theAntinomies; what we have alone been able to show is that, our understandingdepends on the Categories. It remains a mystery why the Ideal stands in needof reason. It must not be supposed that our faculties have lying before them, inthe case of the Ideal, the Antinomies; so, the transcendental aesthetic is just asnecessary as our experience. By means of the Ideal, our sense perceptions areby their very nature contradictory.
Yours sincerely,
Immanuel Kant
The SMTP Basic Structure+------+ +------+ +------+
Spam: • Any kind of un-wanted email messages.• The action of sending such kinds of messages to usenet newsgroups, mailinglists, or any other individuals.
• by year 2000, 7% of Internet mails were spam;
• by year 2004, 60% were spam.
• Bill Gates receives nearly 4 million emails a day – most of which are spam.
How Spam Works?
1. Collecting Email Addresses (Sniffing, Web Registration, Mailing List and Newsgroup,etc.)
2. Open Relay — an SMTP server configured in such a way that it allows anyone on theInternet to relay (i.e. send) email through it.
3. Open Proxy — a proxy which is misconfigured to allow access to anyone on the inter-net.
65
4.3 Mail
Relayed Mail Scenariowx672@cs2:~$ nc wx672.3322.org smtp
• Bayesian Filtering:P (spam|words) = P (words|spam)P (spam)
P (words)
• Greylisting — ”normal” MTAs should attempt retries if given an appropriate tempo-rary failure code for a delivery attempt.
Mail References
[1] M. Crispin. INTERNETMESSAGE ACCESS PROTOCOL - VERSION 4rev1. RFC 3501(Proposed Standard). Updated by RFCs 4466, 4469, 4551, 5032, 5182, 5738, 6186,6858. Internet Engineering Task Force, Mar. 2003.
[2] N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) PartOne: Format of Internet Message Bodies. RFC 2045 (Draft Standard). Updated byRFCs 2184, 2231, 5335, 6532. Internet Engineering Task Force, Nov. 1996.
[3] J. Klensin. Simple Mail Transfer Protocol. RFC 2821 (Proposed Standard). Obsoletedby RFC 5321, updated by RFC 5336. Internet Engineering Task Force, Apr. 2001.
[4] J. Myers and M. Rose. Post Office Protocol - Version 3. RFC 1939 (INTERNET STAN-DARD). Updated by RFCs 1957, 2449, 6186. Internet Engineering Task Force, May1996.
[1] S. Bellovin. Firewall-Friendly FTP. RFC 1579 (Informational). Internet EngineeringTask Force, Feb. 1994.
[2] J. Postel and J. Reynolds. File Transfer Protocol. RFC 959 (INTERNET STANDARD).Updated by RFCs 2228, 2640, 2773, 3659, 5797, 7151. Internet Engineering TaskForce, Oct. 1985.
[3] Wikipedia. File Transfer Protocol — Wikipedia, The Free Encyclopedia. [Online; ac-cessed 21-February-2015]. 2015.
4.5 Peer-to-Peer ApplicationsSee also [5, Sec. 2.6.1, P2P File Distribution].
BitTorrent
To determine which requests she responds to, BitTorrent uses a clever tradingalgorithm. The basic idea is that Alice gives priority to the neighbors that are cur-rently supplying her data at the highest rate. Specifically, for each of her neighbors,Alice continually measures the rate at which she receives bits and determines the fourpeers that are feeding her bits at the highest rate. She then reciprocates by sendingchunks to these same four peers. Every 10 seconds, she recalculates the rates and pos-sibly modifies the set of four peers. In BitTorrent lingo, these four peers are said tobe unchoked. Importantly, every 30 seconds, she also picks one additional neighborat random and sends it chunks. Let’s call the randomly chosen peer Bob. In BitTor-rent lingo, Bob is said to be optimistically unchoked. Because Alice is sending datato Bob, she may become one of Bob’s top four uploaders, in which case Bob wouldstart to send data to Alice. If the rate at which Bob sends data to Alice is high enough,Bob could then, in turn, become one of Alice’s top four uploaders. In other words,every 30 seconds, Alice will randomly choose a new trading partner and initiate trad-ing with that partner. If the two peers are satisfied with the trading, they will put eachother in their top four lists and continue trading with each other until one of the peersfinds a better partner. The effect is that peers capable of uploading at compatible ratestend to find each other. The random neighbor selection also allows new peers to get
150 CHAPTER 2 • APPLICATION LAYER
Tracker
Trading chunks
Peer
Obtainlist ofpeers
Alice
Figure 2.26 � File distribution with BitTorrentP2P References
[1] Bram Cohen. The BitTorrent Protocol Specification, Version 11031. Jan. 10, 2008.[2] Wikipedia. BitTorrent — Wikipedia, The Free Encyclopedia. [Online; accessed 22-
February-2015]. 2015.
References[1] R. Braden. Requirements for Internet Hosts - Communication Layers. RFC 1122
(INTERNET STANDARD). Updated by RFCs 1349, 4379, 5884, 6093, 6298, 6633,6864. Internet Engineering Task Force, Oct. 1989.
[2] K.R. Fall and W.R. Stevens. TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley Professional Computing Series. Pearson Education, 2011.
[3] K. Harrenstien, M.K. Stahl, and E.J. Feinler. DoD Internet host table specification.RFC 952. Updated by RFC 1123. Internet Engineering Task Force, Oct. 1985.
[4] V. Jacobson, R. Braden, and D. Borman. TCP Extensions for High Performance. RFC1323 (Proposed Standard). Obsoleted by RFC 7323. Internet Engineering Task Force,May 1992.
[5] J.F. Kurose and K.W. Ross. Computer Networking: A Top-down Approach. Alwayslearning. Pearson, 2013.
[6] M. Mathis et al. TCP Selective Acknowledgment Options. RFC 2018 (Proposed Stan-dard). Internet Engineering Task Force, Oct. 1996.