Napster: Napster was a peer-to-peer file sharing application that originally launched on June 1, 1999 with an emphasis on digital audio file distribution.
初始时 Web 服务器有一个 socket 作为监听描述符监听端口并在新请求过来时创建与之对应的新的 socket，则在 n 个客户端请求连接时又产生 n 个 socket 作为各个连接的已连接描述符，负责服务器与各个客户端之间的连接状态，而第一个守候 socket 继续等待新的请求并连通
HTTP 是无状态协议 stateless protocol!
服务器向客户发送被请求的文件，但不维护关于客户的任何信息
If a particular client asks for the same object twice in a period of a few seconds, the server does not respond by saying that it just served the object to the client; instead, the server resends the object, as it has completely forgotten what it did earlier.
不同版本的 HTTP
The original version of HTTP is called HTTP/1.0 and dates back to the early 1990’s [RFC 1945].
As of 2020, the majority of HTTP transactions take place over HTTP/1.1 [RFC 7230].
However, increasingly browsers and Web servers also support a new version of HTTP called HTTP/2 [RFC 7540]. At the end of this section, we’ll provide an introduction to HTTP/2.
As an example, suppose a browser is requesting the object http://www.someschool.edu/campus.gif. Here is what happens:
The browser establishes a TCP connection to the Web cache and sends an HTTP request for the object to the Web cache.
The Web cache checks to see if it has a copy of the object stored locally. If it does, the Web cache returns the object within an HTTP response message to the client browser.
If the Web cache does not have the object, the Web cache opens a TCP connection to the origin server, that is, to www.someschool.edu. The Web cache then sends an HTTP request for the object into the cache-to-server TCP connection. After receiving this request, the origin server sends the object within an HTTP response to the Web cache.
When the Web cache receives the object, it stores a copy in its local storage and sends a copy, within an HTTP response message, to the client browser (over the existing TCP connection between the client browser and the Web cache).
HTTP 协议的条件 GET 方法，可以验证缓存中的对象是否最新：如果缓存中的对象拷贝是最新的，就不要封装并发送整个对象，只用发送头部
如何使用条件 GET？
缓存：在 HTTP 请求中使用 GET 方法，并且增加一个首部行 If-modified-since: —— 指定缓存拷贝的日期：
If-modified-since: <date>
服务器：
如果缓存拷贝陈旧没有变化，则响应报文不包含对象：
HTTP/1.0 304 Not Modified
如果缓存拷贝的原对象已经被修改，则响应报文包含对象：
HTTP/1.0 200 OK
<data>
条件 GET 方法举例
To illustrate how the conditional GET operates, let’s walk through an example.
First, on the behalf of a requesting browser, a proxy cache sends a request message to a Web server:
GET /fruit/kiwi. gif
HTTP/1.1 Host: www.exotiquecuisine.com
Second, the Web server sends a response message with the requested object to the cache:
HTTP/1.1 200 OK
Date: Sat, 3 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
Last-Modified: Wed, 9 Sep 2015 09:23:24
Content-Type: image/gif
(data data data data data ...)
The cache forwards the object to the requesting browser but also caches the object locally. Importantly, the cache also stores the last-modified date along with the object. Third, one week later, another browser requests the same object via the cache, and the object is still in the cache. Since this object may have been modified at the Web server in the past week, the cache performs an up-to-date check by issuing a conditional GET. Specifically, the cache sends:
Note that the value of the If-modified-since: header line is exactly equal to the value of the Last-Modified: header line that was sent by the server one week ago. This conditional GET is telling the server to send the object only if the object has been modified since the specified date. Suppose the object has not been modified since 9 Sep 2015 09:23:24. Then, fourth, the Web server sends a response message to the cache:
HTTP/1.1 304 Not Modified
Date: Sat, 10 Oct 2015 15:39:29
Server: Apache/1.3.0 (Unix)
(empty entity body)
We see that in response to the conditional GET, the Web server still sends a response message but does not include the requested object in the response message. Including the requested object would only waste bandwidth and increase user-perceived response time, particularly if the object is large. Note that this last response message has 304 Not Modified in the status line, which tells the cache that it can go ahead and forward its (the proxy cache’s) cached copy of the object to the requesting browser.
HTTP/2
HTTP/2 [RFC 7540], standardized in 2015, was the first new version of HTTP since HTTP/1.1, which was standardized in 1997. Since standardization, HTTP/2 has taken off, with over 40% of the top 10 million websites supporting HTTP/2 in 2020 [W3Techs]. Most browsers—including Google Chrome, Internet Explorer, Safari, Opera, and Firefox—also support HTTP/2.
The primary goals for HTTP/2 are to
reduce perceived (感知到的) latency by enabling request and response multiplexing over a single TCP connection,
provide request prioritization and server push,
and provide efficient compression of HTTP header fields.
HTTP/2 does not change HTTP methods, status codes, URLs, or header fields. Instead, HTTP/2 changes how the data is formatted and transported between the client and server.
HTTP/1.1 and HOL problem
To motivate the need for HTTP/2, recall that HTTP/1.1 uses persistent TCP connections, allowing a Web page to be sent from server to client over a single TCP connection. By having only one TCP connection per Web page, the number of sockets at the server is reduced and each transported Web page gets a fair share of the network bandwidth (as discussed below). ==But developers of Web browsers quickly discovered that sending all the objects in a Web page over a single TCP connection has a Head of Line (HOL) blocking problem==.
仅通过单个 TCP 连接传输一个网页的所有对象有行首阻塞问题。
To understand HOL blocking, consider a Web page that includes an HTML base page, a large video clip near the top of Web page, and many small objects below the video. Further suppose there is a low-to-medium speed bottleneck link (for example, a low-speed wireless link) on the path between server and client. Using a single TCP connection, the video clip will take a long time to pass through the bottleneck link, while the small objects are delayed as they wait behind the video clip; that is, the video clip at the head of the line blocks the small objects behind it.
类比 OS 中的长进程占用了短进程的执行时间，使得短进程不得不等待很久才会得到执行。长消息也是如此，如果加载一个包含视频、文字的网站，先传送视频的话，就会极大地延长网页打开的时间。
How HTTP/1.1 and TCP deal with HOL?
HTTP/1.1 browsers typically work around this problem by opening multiple parallel TCP connections, thereby having objects in the same web page sent in parallel to the browser. This way, the small objects can arrive at and be rendered in the browser much faster, thereby reducing user-perceived delay. TCP congestion control, discussed in detail in Chapter 3, also provides browsers an unintended incentive (预期外的激励，指不能预先确定的) to use multiple parallel TCP connections rather than a single persistent connection. Very roughly speaking, TCP congestion control aims to give each TCP connection sharing a bottleneck link an equal share of the available bandwidth of that link; so if there are n TCP connections operating over a bottleneck link, then each connection approximately gets 1/nth of the bandwidth. By opening multiple parallel TCP connections to transport a single Web page, the browser can “cheat” and grab a larger portion of the link bandwidth. Many HTTP/1.1 browsers open up to six parallel TCP connections not only to circumvent(避免，绕过) HOL blocking but also to obtain more bandwidth.
HTTP/1.1 和 TCP 通过打开多个连接、并发地进行数据传输来避免 HOL 问题，但这并不能根治，而且多连接策略意味着会极大地加大服务器的负载。
The purpose of HTTP/2
One of the primary goals of HTTP/2 is to get rid of (or at least reduce the number of) parallel TCP connections for transporting a single Web page. This not only reduces the number of sockets that need to be open and maintained at servers, but also allows TCP congestion control to operate as intended. But with only one TCP connection to transport a Web page, HTTP/2 requires carefully designed mechanisms to avoid HOL blocking.
HTTP/2 Framing
The HTTP/2 solution for HOL blocking is to break each message into small frames, and interleave the request and response messages on the same TCP connection.
HTTP/2 的解决办法就是将整块的信息打碎成多个小片段，在同一个 TCP 连接中交错地请求、响应——完成传输；
类比 OS 的 RR 调度策略，给每个进程都分配固定的执行时间，执行完一段就让渡 CPU 给其他进程。
To understand this, consider again the example of a Web page consisting of one large video clip and, say, 8 smaller objects. Thus the server will receive 9 concurrent requests from any browser wanting to see this Web page. For each of these requests, the server needs to send 9 competing HTTP response messages to the browser. Suppose all frames are of fixed length, the video clip consists of 1000 frames, and each of the smaller objects consists of two frames. With frame interleaving, after sending one frame from the video clip, the first frames of each of the small objects are sent. Then after sending the second frame of the video clip, the last frames of each of the small objects are sent. Thus, all of the smaller objects are sent after sending a total of 18 frames. If interleaving were not used, the smaller objects would be sent only after sending 1016 frames. Thus the HTTP/2 framing mechanism can significantly decrease user-perceived delay.
The ability to break down an HTTP message into independent frames, interleave them, and then reassemble them on the other end is the single most important enhancement of HTTP/2. The framing is done by the framing sub-layer(组帧子层) of the HTTP/2 protocol. When a server wants to send an HTTP response, the response is processed by the framing sub-layer, where it is broken down into frames. The header field of the response becomes one frame, and the body of the message is broken down into one for more additional frames. The frames of the response are then interleaved by the framing sub-layer in the server with the frames of other responses and sent over the single persistent TCP connection. As the frames arrive at the client, they are first reassembled into the original response messages at the framing sub-layer and then processed by the browser as usual.
Similarly, a client’s HTTP requests are broken into frames and interleaved. In addition to breaking down each HTTP message into independent frames, the framing sublayer also binary encodes the frames. Binary protocols are more efficient to parse, lead to slightly smaller frames, and are less error-prone.
Response Message Prioritization and Server Pushing
Message prioritization allows developers to customize the relative priority of requests to better optimize application performance.
As we just learned, the framing sub-layer organizes messages into parallel streams of data destined to the same requestor. When a client sends concurrent requests to a server, it can prioritize the responses it is requesting by assigning a weight between 1 and 256 to each message. The higher number indicates higher priority. Using these weights, the server can send first the frames for the responses with the highest priority. In addition to this, ==the client also states each message’s dependency on other messages by specifying the ID of the message on which it depends==.
Another feature of HTTP/2 is the ability for a server to send multiple responses for a single client request. That is, in addition to the response to the original request, the server can push additional objects to the client, without the client having to request each one. This is possible since the HTML base page indicates the objects that will be needed to fully render the Web page. So instead of waiting for the HTTP requests for these objects, the server can analyze the HTML page, identify the objects that are needed, and send them to the client before receiving explicit requests for these objects. Server push eliminates the extra latency due to waiting for the requests.
QUIC, discussed in Chapter 3, is a new “transport” protocol that is implemented in the application layer over the bare-bones(简陋的) UDP protocol.
QUIC has several features that are desirable for HTTP, such as
message multiplexing (interleaving),
per-stream flow control,
and low-latency connection establishment.
HTTP/3 is yet a new HTTP protocol that is designed to operate over QUIC. As of 2020, HTTP/3 is described in Internet drafts and has not yet been fully standardized. Many of the HTTP/2 features (such as message interleaving) are subsumed(纳入、归入) by QUIC, allowing for a simpler, streamlined design for HTTP/3.
125 data connection already open; transfer starting
425 Can’t open data connection
452 Error writing file
2.4 EMail（电子邮件）
3个主要组成部分
用户代理(user agent)：发送、接收电子邮件的客户端软件
又名“邮件阅读器”
撰写、编辑和阅读邮件
如Outlook、Foxmail
输出和输入邮件保存在服务器上
注：Web 应用的用户代理：Web 浏览器；FTP 的用户代理：FTP 的客户端软件
邮件服务器(mail server)
简单邮件传输协议：SMTP（Simple Mail Transfer Protocol, SMTP 是发送的协议，EMail 还有拉取的协议包括 POP3、IMAP、HTTP 等等）
A typical message starts its journey in the sender’s user agent, then travels to the sender’s mail server, and then travels to the recipient’s mail server, where it is deposited in the recipient’s mailbox.
EMail: 邮件服务器
邮箱中管理和维护发送给用户的邮件
如果发送失败（不论是自身原因还是对方未接收的原因），邮件都会在 mail server 的报文队列中保持，排队等待后续尝试（邮件服务器通常设置成一段时间间隔发一次）
It is important to observe that SMTP does not normally use intermediate mail servers for sending mail, even when the two mail servers are located at opposite ends of the world. If Alice’s server is in Hong Kong and Bob’s server is in St. Louis, the TCP connection is a direct connection between the Hong Kong and St. Louis servers.
In particular, if Bob’s mail server is down, the message remains in Alice’s mail server and waits for a new attempt — the message does not get placed in some intermediate mail server.
EMail：SMTP
[RFC 2821], [RFC 5321]
使用TCP在客户端和服务器之间传送报文，端口号为25
直接传输：从发送方服务器到接收方服务器
命令/响应交互
命令：ASCII文本
响应：状态码和状态信息
报文必须为7位ASCII码（所有的字节范围为0-127，包括邮件内容）
SMTP, a legacy technology.
For example, it restricts the body (not just the headers) of all mail messages to simple 7-bit ASCII. This restriction made sense in the early 1980s when transmission capacity was scarce and no one was e-mailing large attachments or large image, audio, or video files.
But today, in the multimedia era, the 7-bit ASCII restriction is a bit of a pain — it requires binary multimedia data to be encoded to ASCII before being sent over SMTP; and it requires the corresponding ASCII message to be decoded back to binary after SMTP transport. Recall from Section 2.2 that HTTP does not require multimedia data to be ASCII encoded before transfer.
简单的 SMTP 交互
The ASCII text lines prefaced with C: are exactly the lines the client sends into its TCP socket, and the ASCII text lines prefaced with S: are exactly the lines the server sends into its TCP socket.The following transcript begins as soon as the TCP connection is established.
S: 220 hamburger.edu
C: HELO crepes.fr
S: 250 Hello crepes.fr, pleased to meet you
C: MAIL FROM: <[email protected]>
S: 250 [email protected]... Sender ok
C: RCPT TO: <[email protected]>
S: 250 [email protected] ... Recipient ok
C: DATA
S: 354 Enter mail, end with "." on a line by itself
C: Do you like ketchup?
C: How about pickles?
C: .
S: 250 Message accepted for delivery
C: QUIT
S: 221 hamburger.edu closing connection
As part of the dialogue, the client issued five commands:
HELO (an abbreviation for HELLO),
MAIL FROM,
RCPT TO,
DATA,
and QUIT.
These commands are self-explanatory. The client also sends a line consisting of a single period, which indicates the end of the message to the server. (In ASCII jargon, each message ends with CRLF. CRLF, where CR and LF stand for carriage return (回车) and line feed (换行，没错这是两个键), respectively.)
We mention here that SMTP uses persistent connections: If the sending mail server has several messages to send to the same receiving mail server, it can send all of the messages over the same TCP connection. For each message, the client begins the process with a new MAIL FROM: crepes. fr, designates the end of message with an isolated period, and issues QUIT only after all messages have been sent.
（对于每封邮件，客户端都以新的 MAIL FROM：crepes.fr 开始处理，用一个孤立的句号指定邮件结束，并在所有邮件发送完毕后才发出 QUIT。）
预先准备：建立连接——First, the client SMTP (running on the sending mail server host) has TCP establish a connection to port 25 at the server SMTP (running on the receiving mail server host). If the server is down, the client tries again later.
传输的 3 个阶段
握手：SMTP clients and servers introduce themselves before transferring information. During this SMTP handshaking phase, the SMTP client indicates the e-mail address of the sender (the person who generated the message) and the e-mail address of the recipient.
传输报文：
SMTP can count on the reliable data transfer service of TCP to get the message to the server without errors.
The client then repeats this process over the same TCP connection if it has other messages to send to the server.
关闭：
SMTP：总结
SMTP 使用持久连接，使用 TCP 可靠数据传输服务
SMTP要求报文（首部和主体）为7位ASCII编码
SMTP 服务器使用 CRLF.CRLF 决定报文的尾部
SMTP与HTTP比较：
HTTP：拉协议(pull)——内容提供者在 Web 服务器上装载信息，用户使用 HTTP 从中拉取信息，尤其是 TCP 连接发起自想接收文件的主机；
The header lines and the body of the message are separated by a blank line (that is, by CRLF).
[RFC 5322] specifies the exact format for mail header lines as well as their semantic interpretations.
As with HTTP, each header line contains readable text, consisting of a keyword followed by a colon followed by a value.
Some of the keywords are required and others are optional. Every header must have a From: header line and a To: header line; a header may include a Subject: header line as well as other optional header lines.
It is important to note that these header lines are different from the SMTP commands we studied in Section 2.3.1 (even though they contain some common words such as “from” and “to”). The commands in that section were part of the SMTP handshaking protocol; the header lines examined in this section are part of the mail message itself.
Now let’s consider the path an e-mail message takes when it is sent from Alice to Bob. We just learned that at some point along the path the e-mail message needs to be deposited in Bob’s mail server. This could be done simply by having Alice’s user agent send the message directly to Bob’s mail server.
However, typically the sender’s user agent does not dialogue directly with the recipient’s mail server. Instead, as shown in Figure 2.16, Alice’s user agent uses SMTP or HTTP to deliver the e-mail message into her mail server, then Alice’s mail server uses SMTP (as an SMTP client) to relay the e-mail message to Bob’s mail server.
Why the two-step procedure? Primarily because without relaying through Alice’s mail server, Alice’s user agent doesn’t have any recourse to an unreachable destination mail server. By having Alice first deposit the e-mail in her own mail server, Alice’s mail server can repeatedly try to send the message to Bob’s mail server, say every 30 minutes, until Bob’s mail server becomes operational. (And if Alice’s mail server is down, then she has the recourse of complaining to her system administrator!)
IMAP：Internet 邮件访问协议(Internet Mail Access Protocol) [RFC 1730]
比POP3具备更多特性（更复杂），包括远程目录的维护（远程将报文从一个邮箱搬到另一个邮箱）
在服务器上处理存储的报文
HTTP：Hotmail，Yahoo! Mail等
方便
被替代的 POP3 和越发强大的 HTTP
注意到，上面第八版的 Top-down 课本里插图是仅出现了 IMAP 和 HTTP 两种邮件拉取协议。而第七版的插图是这样：
这是因为 POP3 已经广泛地被 IMAP 替代了。第八版书中这样写到：
Today, there are two common ways for Bob to retrieve his e-mail from a mail server.
If Bob is using Web-based e-mail or a smartphone app (such as Gmail), then the user agent will use HTTP to retrieve Bob’s e-mail. This case requires Bob’s mail server to have an HTTP interface as well as an SMTP interface (to communicate with Alice’s mail server).
The alternative method, typically used with mail clients such as Microsoft Outlook, is to use the Internet Mail Access Protocol (IMAP) defined in RFC 3501.
Both the HTTP and IMAP approaches allow Bob to manage folders, maintained in Bob’s mail server. Bob can move messages into the folders he creates, delete messages, mark messages as important, and so on.
POP3协议
POP3 begins when the user agent (the client) opens a TCP connection to the mail server (the server) on port 110. With the TCP connection established, POP3 progresses through three phases: authorization, transaction, and update.
During the first phase, authorization, the user agent sends a username and a password (in the clear) to authenticate the user.
During the second phase, transaction, the user agent retrieves messages; also during this phase, the user agent can mark messages for deletion, remove deletion marks, and obtain mail statistics.
The third phase, update, occurs after the client has issued the quit command, ending the POP3 session; at this time, the mail server deletes the messages that were marked for deletion.
用户确认阶段
客户端命令：
user：申明用户名
pass：口令
服务器响应
+OK(后跟服务器到客户的数据)
-ERR
事物处理阶段，客户端：
list：报文号列表
retr：根据报文号检索报文
dele：删除
quit
telnet mailServer 110 #通过110端口连接到指定邮件服务器
# 用户确认阶段
S: +OK POP3 server ready
C: user bob
S: +OK #如果服务器验证错误会发送-ERR，下面密码也一样
C: pass hungry
S: +OK user successfully logged on
# 事务处理阶段
C: list #列出所有报文及其长度
S: 1 498
S: 2 912
S: .
C: retr 1
S: <message 1 contents>
S: .
C: dele 1 # 下载并删除模式，如果没有dele指令则下载但不删除。这取决于用户代理程序配置的方式
C: retr 2
S: <message 2 contents>
S: .
C: dele 2
C: quit
S: +OK POP3 server signing off
POP3与IMAP
POP3：本地管理文件夹
先前的例子使用“下载并删除”模式（一共有两种模式：下载并删除、下载并保留）。
如果改变客户机，Bob不能阅读邮件
“下载并保留”：不同客户机上为报文的拷贝，在其他邮件客户端仍能阅读邮件
POP3 在会话中是无状态的
但无论是否保存，POP3 都是在本地邮件服务器保存的，没有给用户提供任何远程访问和管理能力
IMAP：远程管理邮件文件夹
IMAP 服务器将每个报文与一个文件夹联系起来；when a message first arrives at the server, it is associated with the recipient’s INBOX folder.
允许用户用目录来组织报文
IMAP also provides commands that allow users to search remote folders for messages matching specific criteria.
IMAP在会话过程中保留用户状态：
目录名、报文 ID 与目录名之间映射
Another important feature of IMAP is that it has commands that permit a user agent to obtain components of messages. For example, a user agent can obtain just the message header of a message or just one part of a multipart MIME message. This feature is useful when there is a low-bandwidth connection (for example, a slow-speed modem link) between the user agent and its mail server. With a low-bandwidth connection, the user may not want to download all of the messages in its mailbox, particularly avoiding long messages that might contain, for example, an audio or video clip.
HTTP 也能用作邮件访问
More and more users today are sending and accessing their e-mail through their Web browsers. Hotmail introduced Web-based access in the mid 1990s. Now Web-based e-mail is also provided by Google, Yahoo!, as well as just about every major university and corporation. With this service, the user agent is an ordinary Web browser, and the user communicates with its remote mailbox via HTTP.
When a recipient, such as Bob, wants to access a message in his mailbox, the e-mail message is sent from Bob’s mail server to Bob’s browser using the HTTP protocol rather than the POP3 or IMAP protocol. When a sender, such as Alice, wants to send an e-mail message, the e-mail message is sent from her browser to her mail server over HTTP rather than over SMTP. Alice’s mail server, however, still sends messages to, and receives messages from, other mail servers using SMTP.
2.5 DNS (Domain Name System)
域名解析系统(DNS)不是一个给人用的应用，而是一个给其他应用使用的应用，提供域名到 IP 地址的转换，供应用使用。如 Web 应用中，用户输入 URL，Web 浏览器调用 DNS 的解析功能，得到域名对应的 IP 地址
DNS 大致介绍
DNS的必要性
IP地址标识主机、路由器（Everything over IP）（IP地址用于标识、寻址）
但 IP 地址不好记忆（IPv4是一个4字节即32bit 的数字；如果是 IPv6的话是一个16字节128bit 的数字），不便人类使用（没有人类语言的语义）
a distributed database implemented in a hierarchy of DNS servers, and
an application-layer protocol that allows hosts to query the distributed database.
The DNS servers are often UNIX machines running the Berkeley Internet Name Domain (BIND) software [BIND 2020].
The DNS protocol runs over UDP and uses port 53.
DNS 系统需要解决的问题
问题1：如何命名设备
用有意义的字符串：好记，便于人类用使用
解决一个平面命名的重名问题：层次化命名
问题2：如何完成名字到IP地址的转换
分布式的数据库维护（一个节点维护一小个范围）和响应名字查询
问题3：如何维护：增加或者删除一个域，需要在域名系统中做哪些工作
DNS 提供的服务
DNS is commonly employed by other application-layer protocols, including HTTP and SMTP, to translate user-supplied hostnames to IP addresses.
Most important: translate hostname to IP-address
As an example, consider what happens when a browser (that is, an HTTP client), running on some user’s host, requests the URL www.someschool.edu/index.html. In order for the user’s host to be able to send an HTTP request message to the Web server www.someschool.edu , the user’s host must first obtain the IP address of www.someschool.edu. This is done as follows:
The same user machine runs the client side of the DNS application.
The browser extracts the hostname, www.someschool.edu , from the URL and passes the hostname to the client side of the DNS application.
The DNS client sends a query containing the hostname to a DNS server.
The DNS client eventually receives a reply, which includes the IP address for the hostname.
Once the browser receives the IP address from DNS, it can initiate a TCP connection to the HTTP server process located at port 80 at that IP address.
Host aliasing
DNS provides a few other important services in addition to translating hostnames to IP addresses:
Host aliasing. A host with a complicated hostname can have one or more alias names. For example, a hostname such as relay1.west-coast.enterprise.com could have, say, two aliases such as enterprise.com and www.enterprise.com. In this case, the hostname relay1.west-coast.enterprise.com is said to be a canonical hostname (规范主机名). Alias hostnames, when present, are typically more mnemonic (好记的) than canonical hostnames. DNS can be invoked by an application to obtain the canonical hostname for a supplied alias hostname as well as the IP address of the host.
Mail server aliasing. For obvious reasons, it is highly desirable that e-mail addresses be mnemonic. For example, if Bob has an account with Yahoo Mail, Bob’s e-mail address might be as simple as [email protected]. However, the hostname of the Yahoo mail server is more complicated and much less mnemonic than simply yahoo. com (for example, the canonical hostname might be something like relay1.west-coast.yahoo.com). DNS can be invoked by a mail application to obtain the canonical hostname for a supplied alias hostname as well as the IP address of the host. In fact, the MX record (see below) permits a company’s mail server and Web server to have identical (aliased) hostnames; for example, a company’s Web server and mail server can both be called enterprise.com.
Load distribution
Load distribution. DNS is also used to perform load distribution among replicated(冗余的) servers, such as replicated Web servers. Busy sites, such as cnn.com, are replicated over multiple servers, with each server running on a different end system and each having a different IP address. For replicated Web servers, a set of IP addresses is thus associated with one alias hostname. The DNS database contains this set of IP addresses. When clients make a DNS query for a name mapped to a set of addresses, the server responds with the entire set of IP addresses, but rotates the ordering of the addresses within each reply. Because a client typically sends its HTTP request message to the IP address that is listed first in the set, DNS rotation distributes the traffic among the replicated servers. DNS rotation is also used for e-mail so that multiple mail servers can have the same alias name. Also, content distribution companies such as Akamai have used DNS in more sophisticated ways [Dilley 2002] to provide Web content distribution.
From the perspective of the invoking application in the user’s host, DNS is a black box providing a simple, straightforward translation service. But in fact, the black box that implements the service is complex, consisting of a large number of DNS servers distributed around the globe, as well as an application-layer protocol that specifies how the DNS servers and querying hosts communicate.
用户视角下的 DNS 就是一个黑箱，只需要提供 URL，就会得到 IP。
分布式、层次数据库
DNS 不采用集中式(整个网络使用一个 DNS 服务器)数据库的原因
The problems with a centralized design include:
A single point of failure. If the DNS server crashes, so does the entire Internet!
Traffic volume. A single DNS server would have to handle all DNS queries (for all the HTTP requests and e-mail messages generated from hundreds of millions of hosts).
Distant centralized database. A single DNS server cannot be “close to” all the querying clients. If we put the single DNS server in New York City, then all queries from Australia must travel to the other side of the globe, perhaps over slow and congested links. This can lead to significant delays.
Maintenance. The single DNS server would have to keep records for all Internet hosts. Not only would this centralized database be huge, but it would have to be updated frequently to account for every new host.
总之，集中式数据库既不合适、也不可行。
No single DNS server has all of the mappings for all of the hosts in the Internet. Instead, the mappings are distributed across the DNS servers.
上面这句话是对 DNS 分布式机制的最好诠释。
三类 DNS 服务器
DNS 分为三类：root DNS servers, top-level domain (TLD) DNS servers, and authoritative DNS servers：
To understand how these three classes of servers interact, suppose a DNS client wants to determine the IP address for the hostname www.amazon.com.
To a first approximation, the following events will take place. The client first contacts one of the ==root servers, which returns IP addresses for TLD servers for the top-level domain com==.
The client then contacts one of these TLD servers, which returns the IP address of an authoritative server for amazon.com.
Finally, the client contacts one of the authoritative servers for amazon.com, which returns the IP address for the hostname www.amazon.com.
用户→根 DNS 服务器，获得顶级域名的IP→TLD 服务器，获得权威域名的IP→目的主机的IP
More about DNS hierarchy
Root DNS servers. There are more than 1000 root servers instances scattered all over the world, as shown in Figure 2.18. These root servers are copies of 13 different root servers, managed by 12 different organizations, and coordinated through the Internet Assigned Numbers Authority [IANA 2020]. The full list of root name servers, along with the organizations that manage them and their IP addresses can be found at [Root Servers 2020]. Root name servers provide the IP addresses of the TLD servers.
Top-level domain (TLD) servers. For each of the top-level domains—top-level domains such as com, org, net, edu, and gov, and all of the country top-level domains such as uk, fr, ca, and jp —there is TLD server (or server cluster). The company Verisign Global Registry Services maintains the TLD servers for the com top-level domain, and the company Educause maintains the TLD servers for the edu top-level domain. The network infrastructure supporting a TLD can be large and complex; see [Osterweil 2012] for a nice overview of the Verisign network. See [TLD list 2020] for a list of all top-level domains. TLD servers provide the IP addresses for authoritative DNS servers.
Authoritative DNS servers. Every organization with publicly accessible hosts (such as Web servers and mail servers) on the Internet must provide publicly accessible DNS records that map the names of those hosts to IP addresses. An organization’s authoritative DNS server houses these DNS records.
An organization can choose to implement its own authoritative DNS server to hold these records;
alternatively, the organization can pay to have these records stored in an authoritative DNS server of some service provider.
Most universities and large companies implement and maintain their own primary and secondary (backup) authoritative DNS server.
本地 DNS 服务器
There is another important type of DNS server called the local DNS server. A local DNS server does not strictly belong to the hierarchy of servers but is nevertheless central to the DNS architecture. Each ISP—such as a residential ISP or an institutional ISP—has a local DNS server (also called a default name server).
When a host connects to an ISP, the ISP provides the host with the IP addresses of one or more of its local DNS servers(typically through DHCP, which is discussed in Chapter 4). You can easily determine the IP address of your local DNS server by accessing network status windows in Windows or UNIX.
本地域名服务器不在上述 DNS 层次中，实际上是由 ISP 服务商提供给本地用户使用的。当用户的主机连接到 ISP，会通过 DHCP 获得临时 IP 地址，然后可以通过本地域名服务器加快解析到外部网络的速度。
A host’s local DNS server is typically “close to” the host. For an institutional ISP, the local DNS server may be on the same LAN as the host; for a residential ISP, it is typically separated from the host by no more than a few routers. When a host makes a DNS query, the query is sent to the local DNS server, which acts a proxy, forwarding the query into the DNS server hierarchy, as we’ll discuss in more detail below.
DNS 查询实例
Let’s take a look at a simple example. Suppose the host cse.nyu.edu desires the IP address of gaia.cs.umass.edu. Also suppose that NYU’s local DNS server for cse.nyu.edu is called dns.nyu.edu and that an authoritative DNS server for gaia.cs.umass.edu is called dns.umass.edu.
As shown in Figure 2.19, the host cse.nyu.edu first sends a DNS query message to its local DNS server, dns.nyu.edu. The query message contains the hostname to be translated, namely, gaia.cs.umass.edu.
The local DNS server forwards the query message to a root DNS server. The root DNS server takes note of the edu suffix and returns to the local DNS server a list of IP addresses for TLD servers responsible for edu.
The local DNS server then resends the query message to one of these TLD servers. The TLD server takes note of the umass.edu suffix and responds with the IP address of the authoritative DNS server for the University of Massachusetts, namely, dns.umass.edu.
Finally, the local DNS server resends the query message directly to dns.umass.edu, which responds with the IP address of gaia.cs.umass.edu.
Note that in this example, in order to obtain the mapping for one hostname, eight DNS messages were sent: four query messages and four reply messages!
Our previous example assumed that the TLD server knows the authoritative DNS server for the hostname. In general, this is not always true. Instead, the TLD server may know only of an intermediate DNS server, which in turn knows the authoritative DNS server for the hostname. For example, suppose again that the University of Massachusetts has a DNS server for the university, called dns.umass.edu. Also suppose that each of the departments at the University of Massachusetts has its own DNS server, and that each departmental DNS server is authoritative for all hosts in the department. In this case, when the intermediate DNS server, dns.umass.edu, receives a query for a host with a hostname ending with cs.umass.edu, it returns to dns.nyu.edu the IP address of dns.cs.umass.edu, which is authoritative for all hostnames ending with cs.umass.edu. The local DNS server dns.nyu.edu then sends the query to the authoritative DNS server, which returns the desired mapping to the local DNS server, which in turn returns the mapping to the requesting host. In this case, a total of 10 DNS messages are sent!
递归查询和迭代查询
The example shown in Figure 2.19 makes use of both recursive queries and iterative queries.
The query sent from cse.nyu.edu to dns.nyu.edu is a recursive query, since the query asks dns.nyu.edu to obtain the mapping on its behalf.
However, the subsequent three queries are iterative since all of the replies are directly returned to dns.nyu.edu.
In theory, any DNS query can be iterative or recursive. For example, Figure 2.20 shows a DNS query chain for which all of the queries are recursive.
In practice, the queries typically follow the pattern in Figure 2.19: The query from the requesting host to the local DNS server is recursive, and the remaining queries are iterative.
为什么查询要分两种？
递归查询的缺陷：
问题：根服务器的负担太重
解决：迭代查询
DNS caching
上文中可以看到，为了请求一个地址，要进行多次的、重复的 DNS 查询，这可以通过设立 DNS 缓存来优化查询时间和请求次数。
In a query chain, when a DNS server receives a DNS reply (containing, for example, a mapping from a hostname to an IP address), it can cache the mapping in its local memory.
Because hosts and mappings between hostnames and IP addresses are by no means permanent, DNS servers discard cached information after a period of time (often set to two days).
DNS 记录
共同实现 DNS 分布式数据库的所有 DNS 服务器存储了资源记录 Resource Record，RR 提供主机名到 IP 地址的映射。
TTL (time to live)：生存时间，决定了资源记录应当从缓存中删除的时间（权威，缓冲记录）
若 ttl 很长趋于无限大，则指的是权威记录；
若 ttl 为有限值，则为缓冲记录，需要过了 ttl 这么长的时间后将资源记录删除，
一般是其他区域的域名和 IP 地址的关系，需要暂时缓存（为了性能），超过时限后删除（为了一致性，防止域名改变后本权威名字服务器还保留错误的老旧域名））
Value 和 Name 取决于 Type：
Type 类别：本资源记录的类型，用不同的值来标识
Type=A （是什么）
Name 为主机名；Value 为 IP 地址
如：relay1.bar.foo.com, 145.37.93.126, A
Type=NS（在哪里）
Name 中放子域的域名（如 foo. com ）
Value 为该域名的权威服务器的主机名
用于沿着查询链来路由 DNS 查询
如：foo.com, dns.foo.com, NS
Type=CNAME
Name 为规范名字的别名
value 为规范名字
如：foo.com, relay1.bar.foo.com, CNAME
Type=MX
Name 中为邮件服务器的别名
Value 为 Name 对应的邮件服务器的规范名字
资源记录的类型分别对应什么情况的主机名？
If a DNS server is authoritative for a particular hostname, then the DNS server will contain a Type A record for the hostname. (Even if the DNS server is not authoritative, it may contain a Type A record in its cache.)
If a server is not authoritative for a hostname, then the server will contain a Type NS record for the domain that includes the hostname; it will also contain a Type A record that provides the IP address of the DNS server in the Value field of the NS record.
As an example, suppose an edu TLD server is not authoritative for the host gaia.cs.umass.edu. Then this server will contain a record for a domain that includes the host gaia.cs.umass.edu, for example, (umass.edu, dns.umass.edu, NS). The edu TLD server would also contain a Type A record, which maps the DNS server dns.umass.edu to an IP address, for example, (dns.umass.edu, 128.119.40.111, A).
DNS 报文
DNS协议：查询和响应报文的报文格式相同，通过标识位(flags)加以区分
报文首部
标识符 (identification/ID)：16 位。
使用 ID 号，通过查询 ID 和响应 ID 的比对，Name server 可以同时维护相当多的查询，而非等待该 ID 查询完之后再进行下一个查询
flags:
查询/应答
希望递归
递归可用
应答为权威
The first 12 bytes is the header section, which has a number of fields.
The first field is a 16-bit number that identifies the query. This identifier is copied into the reply message to a query, allowing the client to match received replies with sent queries.
There are a number of flags in the flag field.
A 1-bit query/reply flag indicates whether the message is a query (0) or a reply (1).
A 1-bit authoritative flag is set in a reply message when a DNS server is an authoritative server for a queried name.
A 1-bit recursion-desired flag is set when a client (host or DNS server) desires that the DNS server perform recursion when it doesn’t have the record.
A 1-bit recursion-available field is set in a reply if the DNS server supports recursion.
In the header, there are also four number-of fields. These fields indicate the number of occurrences of the four types of data sections that follow the header.
The question section contains information about the query that is being made. This section includes
a name field that contains the name that is being queried, and
a type field that indicates the type of question being asked about the name—for example, a host address associated with a name (Type A) or the mail server for a name (Type MX)
In a reply from a DNS server, the answer section contains the resource records for the name that was originally queried.
Recall that in each resource record there is the Type (for example, A, NS, CNAME, and MX), the Value, and the TTL.
A reply can return multiple RRs in the answer, since a hostname can have multiple IP addresses (for example, for replicated Web servers, as discussed earlier in this section).
The authority section contains records of other authoritative servers.
The additional section contains other helpful records.
For example, the answer field in a reply to an MX query contains a resource record providing the canonical hostname of a mail server. The additional section contains a Type A record providing the IP address for the canonical hostname of the mail server.
维护问题：如何在 DNS 中新增一个域
在上级域的名字服务器中增加两条记录，指向这个新增的子域的域名 和域名服务器的 IP 地址
在新增子域的名字服务器上运行名字服务器，负责本域的名字解析：名字→IP 地址
例子：在 com 域中建立一个“Network Utopia”
到注册登记机构 resigtrar 注册域名 networkutopia.com
需要向该机构提供权威 DNS 服务器（基本的、和辅助的）的名字和 IP 地址, 登记机构在 com TLD 服务器中插入两条 RR 记录：
( dns1.networkutopia.com , 212.212.212.1, A) 维护这个新增子域的名字服务器的域名→维护这个新增子域的名字服务器的 IP 地址
在 networkutopia. com 的权威服务器中确保有
用于 Web 服务器的 www.networkuptopia.com 的类型为 A 的记录
用于邮件服务器 mail.networkutopia.com 的类型为 MX 的记录
现在，这个 Web 站点就可以访问了！让我们来试试：
Suppose Alice in Australia wants to view the Web page www.networkutopia.com.
As discussed earlier, her host will first send a DNS query to her local DNS server.
The local DNS server will then contact a TLD com server. (The local DNS server will also have to contact a root DNS server if the address of a TLD com server is not cached.)
This TLD server contains the Type NS and Type A resource records listed above, because the registrar had these resource records inserted into all of the TLD com servers.
The TLD com server sends a reply to Alice’s local DNS server, with the reply containing the two resource records.
The local DNS server then sends a DNS query to 212.212.212.1, asking for the Type A record corresponding to www.networkutopia.com.
This record provides the IP address of the desired Web server, say, 212.212.71.4, which the local DNS server passes back to Alice’s host.
Alice’s browser can now initiate a TCP connection to the host 212.212.71.4 and send an HTTP request over the connection
则采用 C/S 模式将一个 F 大小的文件分发给 N 个客户端耗时： Dc/s≥max(N×usF,dminF)
对于足够大的 N，C/S 模式的分发时间取决于 N×usF
文件分发时间：P2P模式
服务器传输：最少需要上载一份拷贝
发送 1 个拷贝的时间： usF
客户端：每个客户端必须下载一个拷贝
最小下载带宽的客户耗时： dminF
客户端：所有客户端总体下载量： N×F
除了服务器可以上载，其他所有的 peer 节点都可以上载，因此
最大上载带宽是： us+i=1∑Nui
则采用 P2P 方法将一个 F 大小的文件分发给 N 个客户端耗时的下界： DP2P≥maxusF,dminF,us+i=1∑NuiN×F
分子随着 N 线性变化，每个节点需要下载，整体下载量随着 N 增大…… 分母也是如此，随着 peer 节点的增多每个 peer 也带了服务能力
Figure 2.23 compares the minimum distribution time for the client-server and P2P architectures assuming that all peers have the same upload rate u. In Figure 2.23, we have set usF=1hour, us=10ui, and dmin≥us. Thus, a peer can transmit the entire file in one hour, the server transmission rate is 10 times the peer upload rate, and (for simplicity) the peer download rates are set large enough so as not to have an effect.
We see from Figure 2.23 that for the client-server architecture, the distribution time increases linearly and without bound as the number of peers increases.
However, for the P2P architecture, the minimal distribution time is not only always less than the distribution time of the client-server architecture; it is also less than one hour for any number of peers N.
Thus, applications with the P2P architecture can be self-scaling. This scalability is a direct consequence of peers being redistributors as well as consumers of bits.
BitTorrent is a popular P2P protocol for file distribution [Chao 2011]. In BitTorrent lingo, ==the collection of all peers participating in the distribution of a particular file is called a torrent==.
Peers in a torrent download equal-size chunks of the file from one another, with a typical chunk size of 256 KBytes.
When a peer first joins a torrent, it has no chunks. Over time it accumulates more and more chunks.
While it downloads chunks it also uploads chunks to other peers. Once a peer has acquired the entire file, it may (selfishly) leave the torrent, or (altruistically) remain in the torrent and continue to upload chunks to other peers.
Also, any peer may leave the torrent at any time with only a subset of chunks, and later rejoin the torrent.
Each torrent has an infrastructure node called a tracker. When a peer joins a torrent, it registers itself with the tracker and periodically informs the tracker that it is still in the torrent. In this manner, the tracker keeps track of the peers that are participating in the torrent. A given torrent may have fewer than ten or more than a thousand peers participating at any instant of time.
例：P2P 文件分发 - BitTorrent
当 Alice 加入洪流后，tracker 随机地从洪流中选出 peer 的一个子集（假定 50 个 peer 的子集），并将这 50 个 peer 的 IP 地址发送给 Alice，Alice 持有这张列表并试图与其中的 peer 建立 TCP 连接。若 Alice 成功地与 peer 创建连接，称其为邻近 peer。
随着时间的推移，其中一些对等点可能会离开，其他对等点（在最初的 50 个对等点之外）可能会尝试与 Alice 建立 TCP 连接。因此，一个对等点的邻近对等点会随着时间的推移而波动。
在任何给定时间，每个 peer 都将拥有文件中的一个分块子集，不同的 peer 拥有不同的子集。Alice 会定期（通过 TCP 连接）向每个相邻的对等节点询问它们拥有的数据块列表。如果 Alice 有 L 个不同的邻居，她将获得 L 个数据块列表。有了这些信息，Alice 就可以（再次通过 TCP 连接）请求获得她目前没有的数据块。
每个文件块用 0 或 1 标识是否自己具备该文件块（该方法称为 map）。每个节点都有一个 bit map ，标记自己对用该文件的拥有情况。所有的 peer 节点在该洪流中定期地泛洪/交换 bit map，各个节点就知道了其他节点的情况。
The incentive mechanism for trading just described is often referred to as tit-for-tat(一报还一报) [Cohen 2003]. It has been shown that this incentive scheme can be circumvented [Liogkas 2006; Locher 2006; Piatek 2008]. Nevertheless, the BitTorrent ecosystem is wildly successful.
When a browser in a user’s host is instructed to retrieve a specific video (identified by a URL), the CDN must intercept (截获) the request so that it can
determine a suitable CDN server cluster for that client at that time, and
redirect the client’s request to a server in that cluster.
Most CDNs take advantage of DNS to intercept and redirect requests.
用户如何通过 CDN 访问视频资源？
Suppose a content provider, NetCinema, employs the third-party CDN company, KingCDN, to distribute its videos to its customers. On the NetCinema Web pages, each of its videos is assigned a URL that includes the string “video” and a unique identifier for the video itself; for example, Transformers 7 (变形金刚 7) might be assigned http://video.netcinema.com/6Y7B23V. Six steps then occur, as shown in Figure 2.25:
The user visits the Web page at NetCinema.
When the user clicks on the link http://video.netcinema.com/6Y7B23V, the user’s host sends a DNS query for video.netcinema.com.
The user’s Local DNS Server (LDNS) relays the DNS query to an authoritative DNS server for NetCinema, which observes the string “video” in the hostname video.netcinema.com. To “hand over” the DNS query to KingCDN, instead of returning an IP address, the NetCinema authoritative DNS server returns to the LDNS a hostname in the KingCDN’s domain, for example, a1105.kingcdn.com.
From this point on, the DNS query enters into KingCDN’s private DNS infrastructure. The user’s LDNS then sends a second query, now for a1105.kingcdn.com, and KingCDN’s DNS system eventually returns the IP addresses of a KingCDN content server to the LDNS. It is thus here, within the KingCDN’s DNS system, that the CDN server from which the client will receive its content is specified.
The LDNS forwards the IP address of the content-serving CDN node to the user’s host.
Once the client receives the IP address for a KingCDN content server, it establishes a direct TCP connection with the server at that IP address and issues an HTTP GET request for the video. If DASH is used, the server will first send to the client a manifest file with a list of URLs, one for each version of the video, and the client will dynamically select chunks from the different versions.
集群选择策略
任何 CDN 部署的核心都是集群选择策略，即动态将客户导向 CDN 内的服务器集群或数据中心的机制。CDN 通过客户端的 DNS 查询得知客户端 LDNS 服务器的 IP 地址。在得知该 IP 地址后，CDN 需要根据该 IP 地址选择一个合适的群集。CDN 通常采用专有的集群选择策略。有以下几种策略：
将客户端分配到地理位置最近的集群。
利用商业地理位置数据库，每个 LDNS IP 地址都会映射到一个地理位置。当收到来自某个 LDNS 的 DNS 请求时，CDN 会选择地理位置上最近的集群。
CDN 可以对其集群和客户端之间的延迟和损耗性能进行定期的实时测量。例如，CDN 可以让其每个集群定期向全球所有 LDNS 发送探测信息（如 ping 消息或 DNS 查询）。
这种方法的一个缺点是，许多 LDNS 被配置为不响应此类探测。
CDN 例子：Netflix
2.8 Socket 编程
A typical network application consists of a pair of programs—a client program and a server program—residing in two different end systems. When these two programs are executed, a client process and a server process are created, and these processes communicate with each other by reading from, and writing to, sockets.
There are two types of network applications.
One type is an implementation whose operation is specified in a protocol standard, such as an RFC or some other standards document;
such an application is sometimes referred to as “open,” since the rules specifying its operation are known to all.
For such an implementation, the client and server programs must conform to the rules dictated by the RFC. For example, the client program could be an implementation of the client side of the HTTP protocol.
The other type of network application is a proprietary network application.
In this case, the client and server programs employ an application-layer protocol that has not been openly published in an RFC or elsewhere.
A single developer (or development team) creates both the client and server programs, and the developer has complete control over what goes in the code.
应该使用什么端口号？
Recall also that when a client or server program implements a protocol defined by an RFC, it should use the well-known port number associated with the protocol;
conversely, when developing a proprietary application, the developer must be careful to avoid using such well-known port numbers.
// client.cvoid main(int argc, char *argv[]){ struct sockaddr_in sad; // structure to hold an IP address int clientSocket; // socket descriptor struct hostent *ptrh; // pointer to a host table entry char Sentence[128]; char modifiedSentence[128]; host = argv[1]; port = atoi(argv[2]); clientSocket = socket(PF_INET, SOCK_DGRAM, 0); // 创建客户端socket，没有连接到服务器 /* determine the server's address */ memset((char *)&sad, 0, sizeof(sad)); // clear sockaddr structure sad.sin_family = AF_INET; // set family to Internet sad.sin_port = htons((unsigned short)port); ptrh = gethostbyname(host); /* Convert host name to IP address */ memcpy(&sad.sin_addr, ptrh->h_addr, ptrh->h_length); gets(Sentence) // Get input stream from user addr_len = sizeof(struct sockaddr); n = sendto(clientSocket, Sentence, strlen(Sentence)+1, (struct sockaddr *) &sad, addr_len); // Send line to server n = recvfrom(clientSocket, modifiedSentence, sizeof(modifiedSentence), (struct sockaddr *) &sad, &addr_len); // Read line from server printf("FROM SERVER: %s\n", modifiedSentence); close(clientSocket); // Close connection}
C服务器（UDP）
// server.cvoid main(int argc, char *argv[]){ struct sockaddr_in sad; // structure to hold an IP address struct sockaddr_in cad; int serverSocket; // socket descriptor struct hostent *ptrh; // pointer to a host table entry char clientSentence[128]; char capitalizedSentence[128]; port = atoi(argv[1]); /* Create welcoming socket at port & Bind a local address */ serverSocket = socket(PF_INET, SOCK_DGRAM, 0); memset((char *)&sad,0,sizeof(sad)); // clear sockaddr structure sad.sin_family = AF_INET; // set family to Internet sad.sin_addr.s_addr = INADDR_ANY; // set the local IP address sad.sin_port = htons((unsigned short)port); // set the port number bind(serverSocket, (struct sockaddr *) &sad, sizeof(sad)); while(1): { n = recvfrom(serverSocket, clientSentence, sizeof(clientSentence), 0, (struct sockaddr *) &cad, &addr_len); // Receive messages from clients /* capitalize Sentence and store the result in capitalizedSentence */ n = sendto(serverSocket, capitalizedSentence, strlen(capitalizedSentence)+1, (struct sockaddr *) &cad, &addr_len); // Write out the result to socket } // End of while loop, loop back and wait for another client connection}
// client.cvoid main(int argc, char *argv[]) // 两个参数，第一个指明服务器端域名，第二个指明服务器端守候的端口号（注：argv[0]为应用程序名，这里为"client.c"）{ struct socketaddr_in sad; // structure to hold an IP address of server int clientSocket; // socket descriptor struct hostent *ptrh; //pointer to a host table entry char Sentence[128]; char modifiedSentence[128]; host = argv[1]; // 第一个参数放主机域名 port = atoi(argv[2]); // 第二个参数放置端口号，将字符串转变为整型 /* Create client socket, connect to server */ clientSocket = socket(PF_INET, SOCK_STREAM, 0); memset((char *) &sad, 0, sizeof(sad)); // clear socketaddr structure sad.sin_family = AF_INET; // set family to Internet sad.sin_port = htons((unsigned short)port); ptrh = gethostbyname(host); // 调用解析器，得到一个结构体的指针，指针中相应放置IP地址 // convert host name to IP address memcpy(&sad.sin_addr, ptrh->h_addr, ptrh->h_length); // copy IP address to sad.sin_addr connect(clientSocket, (struct socketaddr *) &sad, sizeof(sad)); gets(Sentence); // Get input stream from user n = write(clientSocket, Sentence, strlen(Sentence)+1); // Send line to server n = read(clientSocket, modifiedSentence, sizeof(modifiedSentence)); // Read line from server printf("FROM SERVER: %s\n", modifiedSentence); close(clientSocket); // Close connection;}
C服务器（TCP）
// server.cvoid main(int argc, char *argv[]){ struct socketaddr_in sad; // structure to hold an IP address of server struct socketaddr_in cad; // client int welcomeSocket, connectionSocket; // socket descriptor struct hostent *ptrh; // pointer to a host table entry char clientSentence[128]; char capitalizedSentence[128]; port = atoi(argv[1]); /* Create welcoming socket at port & Bind a local address */ welcomeSocket = socket(PF_INET, SOCK_STREAM, 0); memset((char *) &sad, 0, sizeof(sad)); // clear socketaddr structure sad.sin_family = AF_INET; // set family to Internet sad.sin_addr.s_addr = INADDR_ANY; // set the local IP address sad.sin_port = htons((unsigned short)port); // set the port number bind(welcomeSocket, (struct sockaddr *) &sad, sizeof(sad)); /* Specify the maximum number of clients that can be queued */ listen(welcomeSocket, 10) // 队列长度为10，超过10个连接建立请求就拒绝 while(1): { connectionSocket = accept(welcomeSocket, (struct sockaddr *) &cad, &alen); // Wait on welcoming socket for contact by a client n = read(connectionSocket, clientSentence, sizeof(clientSentence)); /* capitalize Sentence and store the result in capitalizedSentence */ n = write(connectionSocket, capitalizedSentence, strlen(capitalizedSentence)+1) // Write out the result to socket close(connectionSocket); } // End of while loop, loop back and wait for another client connection}
客户-服务器（C/S）体系结构：服务器是中心，资源在服务器，客户端请求服务器传回资源
假设：
假设：
A typical message starts its journey in the sender’s user agent, then travels to the sender’s mail server, and then travels to the recipient’s mail server, where it is deposited in the recipient’s mailbox.
这是因为 POP3 已经广泛地被 IMAP 替代了。第八版书中这样写到： Today, there are two common ways for Bob to retrieve his e-mail from a mail server.
To understand how these three classes of servers interact, suppose a DNS client wants to determine the IP address for the hostname 
Let’s take a look at a simple example. Suppose the host 
In practice, the queries typically follow the pattern in Figure 2.19: The query from the requesting host to the local DNS server is recursive, and the remaining queries are iterative.
Figure 2.23 compares the minimum distribution time for the client-server and P2P architectures assuming that all peers have the same upload rate u. In Figure 2.23, we have set , , and . Thus, a peer can transmit the entire file in one hour, the server transmission rate is 10 times the peer upload rate, and (for simplicity) the peer download rates are set large enough so as not to have an effect.
Each torrent has an infrastructure node called a tracker. When a peer joins a torrent, it registers itself with the tracker and periodically informs the tracker that it is still in the torrent. In this manner, the tracker keeps track of the peers that are participating in the torrent. A given torrent may have fewer than ten or more than a thousand peers participating at any instant of time.
