计算机网络-自顶向下方法-笔记【第2章-应用层】

学习的课程及图片来源：中科大郑烇、杨坚全套《计算机网络（自顶向下方法第7版，James F.Kurose，Keith W.Ross）》课程

文章目录

计算机网络-自顶向下方法-笔记【第2章-应用层】
2应用层
- 2.1应用层原理
- - 问题一
  - 问题二
  - - TCP socket
    - UDP socket
  - 问题三
- 2.2 Web and HTTP
- - HTTP连接
  - - 非持久连接
    - 持久连接
  - HTTP请求报文
  - HTTP响应报文
  - Cookies
  - Web Cache 代理服务器proxy server
- 2.3 FTP
- 2.4 E-Mail
- - SMTP
  - POP3
  - IMAP
- 2.5 DNS
- - 问题一
  - 问题二
  - - 名字解析过程
    - DNS协议、报文
  - 问题三
  - nslook
- 2.5 P2P应用
- - P2P的管理模式
  - - 非结构化P2P
    - - 集中式目录
      - 完全分布式
      - 混合体
    - DHT(分布式散列表)（结构化）P2P
  - BitTorrent
- 2.7 CDN
- - DASH 基于HTTP的动态自适应流
  - CDN
- 2.8 TCP socket编程
- 2.9 UDP socket
- 2.10 小结
- 2.9 UDP socket
- 2.10 小结

2应用层

2.1应用层原理

应用层的协议是最多的

网络应用在端系统中部署

即时通讯，如QQ等

客户端进程是主动的，服务器进程是被动的

P2P的会话中也有C和S之分

应用进程需要解决：标识（将自己和其他应用进程区分开）和寻址（让对方能够找到自己）

层间服务的地点（SAP）和形式（原语）

问题一

要标识和寻址一个应用进程，需要3个要素：主机IP，使用TCP还是UDP，TCP/UDP的端口号

本质上是由端口号来区分不同的应用进程，TCP/UDP均为16bit的端口号

用IP和port标识端节点 end point 本质上主机进程的通信由2个端节点构成

问题二

层间接口需要携带的3个信息：内容即SDU，谁传的（IP+port）【否则就不能由对方传回来了】，传给谁（IP+port）

TCP/UDP实体封装源和目的的端口号和数据，进一步交给IP实体来封装源IP和目标IP

采用套接字 socket减少层间传输的信息量，避免在一次连接过程中频繁地封装谁传的/传给谁的信息

socket就是一个整数，代表了源IP，源端口，目标IP，目标端口的四元组(TCP)。在UDP中是源IP，源端口号的二元组。代表了会话session关系，而不仅仅是主机的标识，一个进程和多个不同的进程进行连接有不同的socket

socket是本地的标识，对方并不知道，是本地OS管理的4元组，为了便于管理而引入的

TCP socket

便于应用层和传输层的约定【其他层不知道，对方更不知道】，建立连接时操作系统返回一个socket整数
所以发送时应用层的应用进程只要使用这个socket整数，OS根据socket表就知道上面的四元组，也即在传输层可以得到对应的四元组，使得穿过层间的信息量最少【只需两个：socket和SDU】，而不必在应用进程中每次都指定四元组
收的时候根据收到的四元组可以根据建立起的socket的表找到对应的socket，再找到哪个应用进程创建了这个socket，从而把数据发给相应的应用进程

UDP socket

UDP每次的报文都是独立的，可能上次发给A，下次就发给B

UDP socket只代表本地IP和本地端口，不代表会话关系，因为UDP是无连接的

因此发送报文时应用层的应用进程传给传输层的UDP实体需要三个信息：UDP socket、目标IP和端口、SDU
同理在接收报文时传输层要将对方的IP和port传给对应的应用进程，让其知道是谁传来的

问题三

实体是指和网络交互有关的，实现协议的软硬件部分，而其他部分就不是网络中讲的实体了，如应用程序的应用协议是我们说的实体，但其他部分IO处理等就不是了，如html不是协议的一部分

UDP似乎什么服务都不能提供，那能不能直接用IP协议呢，当然是不能的，UDP能够区分出进程：

SSL Secure Sockets Layer 安全套接字协议及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层与应用层之间对网络连接进行加密

SSL在TCP上实现，位于应用层，应用采用SSL库
如https中的s就是指SSL Hyper Text Transfer Protocol over Secure Socket Layer

2.2 Web and HTTP

web是一种应用，http是支持web应用的协议

web网页本身是对象，网页中嵌了对象，但不是对象本身，而是对象的链接，任何对象都可以由URL唯一标识 uniform resource locator统一资源定位系统

如果支持匿名访问，那么用户名口令可以省略

客户端是浏览器，服务端是服务器

服务器应用层会有一个特殊的socket wait socket守护socket，守护在80端口，当有其他web客户端与服务器建立请求时会产生新的socket，服务器可以并发和多个web客户端连接，这种是连接socket

浏览器得到html文件后会将其画出来，其中的图片等资源会通过URL又去请求不同的其他服务器，得到后插入。得到资源后TCP连接就会关闭

HTTP是无状态的，即不维护客户的任何信息，仅仅是建立连接，关闭连接，在此之前和在结束之后，服务器不会有客户的任何信息，相当于没有记忆

HTTP连接

请求报文很短，传输时间一般可以忽略不计，但返回的对象资源需要传输时间*【注意这个不是传播时间，传播时间还是有的，局域网忽略不计】*

HTTP 1.0默认非持久连接，每次请求返回对象资源后就会关闭连接，如果客户在这个服务器上有多个请求，那么要多次TCP连接

HTTP 1.1默认持久连接，在返回对象资源后连接不会关闭，如果还有请求可以直接使用之前建立的连接下载（可以在报文的首部行中设置connection : close来关闭）

非持久连接

往返时间RTT round-trip time

所以一次http请求需要2RTT+对象的传输时间

持久连接

需要在一个服务器上请求多个对象

非流水线方式：一次请求得到一个对象回来后，然后再发出第二个请求

流水线方式：客户端不等待对象回来，而是发出第一个请求后再发出第二个请求，之后对象依次回来。HTTP 1.1默认方式

HTTP请求报文

请求报文和响应报文两种

两种报文都是ASCII码可读的，都是用ASCII编码的【是早期为了便于调试而采取的措施】

请求报文格式：

请求行/命令行：GET(获取HTML head和body)、POST(上传)、HEAD(获取头，只需要HTML文件的head，不要body，一般是搜索引擎来建立索引的)

HTTP 1.1增加了PUT和DELETE

PUT用来改资源，Post用来增资源

HTTP中GET，POST和PUT的区别
首部行
(一个额外回车换行)

在请求行和首部行的每一行都是有回车换行的 CR LF 【Carriage Return 对应\r 回车 Linefeed 对应\n 换行】
可能的实体行

提交表单信息：

post：将表单放在实体部分
get：将表单信息放在URL中上载，即?后表示参数，参数名=参数值，不同参数用&隔开

HTTP响应报文

响应报文格式：

状态行：协议版本，状态码，状态信息(对状态码的解释，如OK)
首部行：包含Last-Modified 记录修改时间，从而保证后面所讲的缓存能够与服务器内容保持一致

HTTP需要自己维护报文的界限，因为TCP是以字节流的形式传输的（UDP是报文形式），因此报文的字节数很重要
(一个额外的\r \n)
数据

Cookies

Cookies弥补了HTTP无状态带来的一些问题

客户端第一次请求后，服务端在响应报文的头部加上一个cookies并保存在服务器的数据库中，客户端收到cookies由浏览器保管*(至于怎么保存，协议不管，协议只规范cookies这个传输过程)*，下次客户端发送请求时，会在请求报文的头部加上cookies，服务端对比cookies就能确定请求的客户端是谁了

Web Cache 代理服务器proxy server

因为热点总是被更多的人访问，所以缓存是很有效的

排队延迟计算公式

但有风险，可能服务器中发生改变，但缓存中没变，因此proxy server会使用Conditional GET向服务器发送请求，并在头部加入了**If-modified-since: **的条件
如果没有修改，那么服务器返回304 Not Modified表示没有修改；如果修改了，那么就和GET命令完全一样，将对象返回给proxy server 200 OK

2.3 FTP

早期的文件分发方式

客户端和服务器的21号端口建立TCP连接，这个连接称为控制连接，完成用户认证之后客户端可以向服务器发出一系列指令，如list等

当客户端发出下载命令时，服务器会主动和客户端的20号端口建立TCP连接，称为数据连接

控制和数据传输在分别两个连接上进行，把控制连接称为带外(out of band)，带内即数据连接

FTP是有状态的，需要维护用户信息

命令以ASCII文本形式传输

2.4 E-Mail

三个主要组成部分：

用户代理 user agent：写邮件的软件，因此这个软件就是邮件应用的代理（如web应用的代理是浏览器）
邮件服务器 mail servers：守护在25号端口

包含
- 邮箱(mailbox contains incoming messages for user。注意是保存发给用户的邮件，而不是发出去的邮件)
- 报文队列 message queue contains outgoing (to be sent) mail messages
协议：

发送协议：SMTP

拉取协议：POP3，IMAP，HTTP

过程：用户代理将邮件发给邮件服务器**（使用SMTP），在邮件服务器的队列中，然后邮件服务器按照队列顺序逐个将邮件发送给对应的邮件服务器（使用SMTP），对应的邮件服务器收到邮件后存储在对应用户的邮箱mailbox中，该用户通过它的用户代理从它在邮件服务器的邮箱中拉取邮件（使用POP3等）**，在用户代理上呈现

SMTP

SMTP 简单邮件传输协议 Simple Mail Transfer Protocol

所有报文请求和响应以及邮件本身的内容都必须是7位ASCII码，即高位为0的可打印字符，不允许超过ASCII码的范围【这是最原始的形式，但不能满足传输中文，附件的要求，因此下面有MIME】

如果client发完一个邮件后，还有到达这个服务器的邮件，那么会继续发，直达client没有要发给它的邮件了，那么发出QUIT命令终止

在一次连接中可以发很多的邮件，而不是连接一次仅发送一个

因为都是ASCII码，所以外面可以手动输入上面的过程来模拟用户代理发送邮件

使用telnet程序连接qq smtp协议邮箱服务器发送邮件

HTTP一个响应报文仅一个对象，即比如客户群向服务器请求一个html文件，那么html文件就是这个对象，html中的每个图片对象不会包含在其中，只会包含一个URL
SMTP则会将多个对象包含在一个报文中，比如发送附件有10张图片，一个录音等，都是封装在一个报文中发送的

首部行：如to、from、subject(即title)、cc(即抄送)

注意不是MAIL FROM, RCPT TO的命令
主体

MIME 多媒体邮件拓展 multimedia mail extension

使用base64编码，将不能用ASCII表示的文本用ASCII表示出来，从而拓展了可以传输的内容，这边base64编码，对方再解码即可

可以直接使用HTTP来下载邮件（HTTP本身就能上载和下载）

POP3

邮局访问协议 Post Office Protocol

list后显示邮件编号和字节大小

IMAP

互联网邮件访问协议 Internet Mail Access Protocol

比POP3更复杂，允许用户在服务器上建立目录来管理邮件，因此需要保留用户状态

而POP3没有这样的功能，因此是无状态的

2.5 DNS

域名解析系统/域名服务器 Domain Name System

DNS不是给人使用的应用，而是给其他应用使用的应用，主要实现域名到IP地址的转换，还有其他的功能

域名用平面化的命名很容易重复，因此应该使用层次化的命名

使用一台设备解析域名是不可行的，因此分布式的维护和解析域名（多个服务器）

DNS运行在UDP的53号端口，很强的事务性，询问域名-IP，响应即可，没必要建立连接，且报文长度不超过 UDP 的 512 B 限制

互联网的很多核心功能是在网络边缘的端系统上的应用层的应用进程实现的，如DNS

DNS：

域名到IP地址的转换（主要）
主机别名到规范名字的转换

如www.baidu.com，这个名字即为别名，不可能只有一台服务器维护百度网站，背后是一堆的服务器，因此需要将这个别名转化成具体哪个服务器的规范命名，所以转换得到的IP地址是这个服务器的IP地址【别名→规范名字→IP】
邮件服务器别名到规范名字的转换
负载均衡 load distribution 在主机别名到规范命名时选择负载较小的服务器

问题一

对主机命名从树叶往树根走，每过一层加一个dot.区分

对域命名从树枝往上走，每过一层加一个dot.区分

如果只有一个root，那么万一宕机了，那么全部都不能使用，因此一共有13个根域名服务器，可以从最近的开始root往下找，如果宕机了，可以换成别的root。【事实上有上百台根域名服务器，由 13 个机构维护，逻辑上是 13 个根域名服务器】

域的划分是逻辑的，网络的划分是物理的

问题二

根据情况划分区域，尽可能均衡，zone和zone之间是互不相交的

对于一个区域所属的名字服务器，这个名字服务器中的信息是权威的，但在其他区域内，就不是权威的了（下面介绍为什么在其他区域也能发挥作用）

域名服务器可以划分为以下四种不同的类型:

根域名服务器 根域名服务器是最高层次的域名服务器。每个根域名服务器都知道所有的顶级域名服务器的域名及其IP地址。因特网上共有13个不同IP地址的根域名服务器。当本地域名服务器向根域名服务器发出查询请求时，路由器就把查询请求报文转发到离这个DNS客户最近的一个根域名服务器。这就加快了DNS的查询过程，同时也更合理地利用了因特网的资源。

顶级域名服务器 这些域名服务器负责管理在该顶级域名服务器注册的所有二级域名。当收到DNS查询请求时就给出相应的回答（可能是最后的结果，也可能是下一级权限域名服务器的IP地址)。

权限域名服务器 这些域名服务器负责管理某个区的域名。每一个主机的域名都必须在某个权限域名服务器处注册登记。因此权限域名服务器知道其管辖的域名与IP地址的映射关系。另外，权限域名服务器还知道其下级域名服务器的地址。

本地域名服务器 本地域名服务器不属于上述的域名服务器的等级结构。当一个主机发出DNS请求报文时，这个报文就首先被送往该主机的本地域名服务器。本地域名服务器起着代理的作用，会将该报文转发到上述的域名服务器的等级结构中。本地域名服务器离用户较近，一般不超过几个路由器的距离，也有可能就在同一个局域网中。本地域名服务器的IP地址需要直接配置在需要域名解析的主机中。

TLD Top-level Domain

例如太平洋岛国图瓦卢的顶级域名是tv，因此将其卖给了电视公司，所以不再是国家级顶级域名

资源记录 resource records

TTL 生存时间 对于权威记录，那么为无限大，而如果是在别的区域名字服务器中的记录，即非权威，是缓存在这里的，为的是提高性能和速度，默认生存时间为2天，2天后就会把记录删除，为的是保持和权威服务器的一致性

NS即上层域中要保存其子域的指针，保存了子域所属的权威服务器的域名，因此要访问这个DNS服务器，还需要有一条TYPE=A的记录来得到这个服务器的IP地址

除了A以外的TYPE都是得到名字

一台主机要上网需要4个信息：

①IP ②子网掩码 ③default gateway默认网关 ④local name server DNS服务器

这些信息是自动分配或者手动分配的

其实可以指定任意一台DNS作为local name server ，但local name server 一般设置比较近的/位于同一个子网的，速度更快

本地域名服务器起着代理的作用，会将该报文转发到域名服务器的等级结构中。本地域名服务器离用户较近，一般不超过几个路由器的距离，也有可能就在同一个局域网中。本地域名服务器的IP地址需要直接配置在需要域名解析的主机中。

名字解析过程

递归查询

当不在区域内/缓存中没有时，local name server 联系13个根名字服务器中的一个，让根服务器代替本地DNS从根往下找，当然根服务器也让下一级服务器返回它查到的结果，递归下去，最后由根服务器返回得到的结果给本地DNS，但这样根服务器压力很大，从它这个引申出一大堆递归【就像递归消耗很大一样】

迭代查询

还是先问根名字服务器，但根服务器不知道的话，只是给出下一级服务器的地址，让本地DNS去问它，然后由本地服务器去逐个询问，最终由权威服务器告诉本地DNS

如果得到了这个域名-IP映射，本地DNS会缓存下来默认两天

不但在本地域名服务器中需要高速缓存，在用户主机中也很需要。

通常采用以下模式：从请求主机到本地域名服务器的查询是递归查询，而其余的查询是迭代查询。

DNS解析：浏览器缓存——》系统hosts文件——》本地DNS解析器缓存——》本地域名服务器（本地配置区域资源、本地域名服务器缓存)——》根域名服务器——》主域名服务器——》下一级域名域名服务器客户端——》本地域名服务器（递归查询) 本地域名服务器—》DNS服务器的交互查询是迭代查询

DNS协议、报文

ID号可以使得查询过程流水线化，如果没有ID号，那么必须等上次查询完成才能发出下次的查询

DNS查询和响应的报文格式一样，根据flags判断是查询还是响应

问题三

增加一个域需要增加两条信息：①该域的域名和其DNS名字的对应关系 ②该DNS名字和DNS的IP的对应关系

DNS比较健壮

nslook

在 cmd 中使用 nslook 程序可以进行域名解析，此外解析会自动在输入的域名后面加上当前 DNS 的域名，因此如下

如果不是当前域名下的网站，那么会逐个向上查询，根据请求可以看到，这里使用的是递归查询，所有结果都由 DNS 返回给主机

2.5 P2P应用

一类P2P应用

当N很小时，服务器的能力很强，客户端的下载速度是瓶颈，随着N增加，服务器成为瓶颈，时间线性增加

流媒体也是类似的，因此一个视频看的人越多反而越流畅传统媒体—>流媒体—>加P2P的流媒体的演变之路

P2P的管理模式

非结构化P2P

peer和peer之间的有相互的TCP关系，则两者之间有一条边，这个边是应用层上逻辑的，事实上两个主机之间可能会经过很多的路由器。节点和节点之间边的关系是任意的，构成的overlay 覆盖网是任意的，称为非结构化

集中式目录

目录服务器维护了哪些IP在线；哪些IP具有哪些资源

完全分布式

一个主机向与之逻辑上连接的所有主机发出查询（假定已经构成了覆盖网），然后一传十，十传百的形式泛洪flooding查询。

会使用TTL来限制泛洪的跳数；或者记录自己已经查询过了，避免回环

覆盖网的构建：在下载Gnutella软件时会有一个表，其中是很可能在线的节点，本主机向这些节点发送ping，如果这些节点中有在线的，再向它的所有邻居发送ping，和上面的泛洪一样，所有收到ping的节点以pong回应，本主机只要选择若干个节点建立TCP连接当作邻居即可。

当一个节点退出时，只要向其邻居发送即可，这些邻居各自再去找一个新的邻居以维持邻居树目

混合体

hash作为文件的唯一标识

DHT(分布式散列表)（结构化）P2P

节点与节点之间是可以构成环，树的关系，是有结构的

如环状：每个节点将其IP地址做哈希，根据hash值从小到大首位相连（逻辑），然后文件也同样做哈希，约定好如上面hash值为6~88的文件存储在hash为88的peer节点中。这样的P2P网络模式有效减少了资源定位的开销，提高了P2P 网络的可扩展性

BitTorrent

非结构化P2P，可以看作混合体式

把文件分成若干个256KB的块

BT工作原理：在文件网站/搜索引擎中下载torrent文件，其中包含了对应文件的Tracker Server，然后向Tracker Server发出请求，它会分配一些peer节点的列表给请求客户端，从而请求客户端加入洪流，互通有无：拿出自己多余的东西给对方，与之进行交换，以得到自己所缺少的东西

Torrent洪流：相当于一个小组

BitMap标识一个文件的块的拥有情况，比如10表示拥有这个文件的第一个块，但没有第二个块。通过bitmap交换就可以知道相互之间的块的拥有情况

新加入Torrent的节点随机的向其他的节点请求块，因为此时什么都没有，bitmap都是0，当达到4个1后，优先请求稀缺的块，即在洪流中持有该块的节点数目很少的块。这样可以让稀缺的块逐渐不稀缺，有利于集体利益

并且有一个策略：如果作为服务方，会优先向为我提供服务最好的节点提供服务，是一种你对我好，我对你好的模式

因此新加入的节点得到稀缺块后，别人向他请求的会更多，那么根据策略，他得到别人服务的机会会更大，这样就可以将集体的利益转化成个人利益

因为请求的节点数大于能服务的节点数，所以需要排队，Alice每隔30s随机选择一个节点，而不是根据之前周期该节点对Alice提供的服务进行评估优先选择。这样优化疏通可能可以导致如下的情况

2.7 CDN

DASH 基于HTTP的动态自适应流

可以看出 HTTP 可不仅仅只用于 web，还可以用于文件的上下载、音视频的播放。HTTP 就是一个传输协议，和应用无关。

将每个块编码于不同的码率，形成多个内容相同，码率不同的块，分别独立存储，提前部署，可能分布于不同服务器，可以是源服务器，或者缓存服务器

所有的这些块（不同内容/不同码率）用告示文件 manifest file记录它们的URL、码率、时长等信息

客户端根据带宽和缓冲区的情况动态地决定请求什么样的块，什么编码速率的块

DASH 解决了不同客户端、不同网络情况的需求问题

CDN

CDN解决的是单个服务器向大量用户提供服务的质量低的问题

ICP需要买CDN运营商的服务，从而提高他们为用户提高的服务质量

内容加速服务：CDN运营商部署了很多的缓存节点，客户端不需要向源服务器请求，而是可以在中间域名解析重定向到离它最近，服务质量最好的缓存节点

显然，前提是ICP要提前将内容部署在缓存节点中，但选择哪些内容部署，是一个策略问题（根据二八定律，一般选择热门的内容部署）

CDN运营商部署缓存节点的方式：

enter deep，将 CDN 服务器深入到许多接入网。 就是在很多的 local ISP 的范围内部署了很多的缓存节点，把一些内容预先部署到这一缓存节点当中。

这种部署方式更接近用户，节点数量多、离用户近，用户请求资源时跳数更少，网络带宽大。

但是因为部署的节点非常靠下，所以需要部署非常多的节点，这些节点管理起来很困难。
bring home， 部署在少数(10个左右)关键位置节点上，比如将服务器簇安装于 POP （网络服务提供点 Point of presence）附近，离若干一级 ISP POP 较近的位置。就是在一些上层的 ISP，有很多的数据中心机房的关键节点，然后我选的位置离那些关键数据中心机房比较近。

这样的话，只要我卡住这些关键的位置，也可以向用户提供一些好的服务。但相比于enter deep服务稍弱

CDN位于应用层提供服务 over the top

客户端要访问URL上的视频

【如果采用了DASH】 ：先要获取告示文件（如下面的网飞的例子中），然后去动态逐个请求每个块，比如一个块的地址在源服务器并且缓存在了CDN中，那么和上图的流程一样

【如果不考虑DASH】：那么就相当于ICP把整个视频缓存在了CDN服务器中，客户端直接去根据上图流程访问到CDN服务器上的视频
客户端向local DNS请求域名解析
local DNS再去请求权威名字服务器的域名解析

权威名字服务器知道哪些内容需要加速，因此可以将这个url的解析重定向，返回一个新的域名地址【即视频位于的CDN缓存服务器的URL】给local DNS
local DNS再去解析这个域名地址，如果没有缓存，那么同理要请求CDN运营商的权威名字服务器，然后得到CDN服务器的IP
local DNS将IP返回给客户端，客户端去请求这个IP即可

2.8 TCP socket编程

应用进程只需要借助socket传和收即可，是逻辑是上的传输，不必关心真正是怎么传输的

字节流保证是可靠的，但不保证报文和报文之间的界限

创建-捆绑-等待

阻塞式即如果没有发送过来的用户连接，那么函数就在这里阻塞，不往下走

sockaddr_in是代表了一个端节点

这个数据结构不仅可以用于ip的通讯，也可以用于ipx的通讯，所以是地址簇

IP地址位于h_addr_list[0]

sad就是sockaddr_in结构体

客户端不需要bind，而服务器需要bind，如果不绑定，那么客户端不知道去找谁，但客户端OS会隐含地bind

当client connect【将socket表项的对方IP，port填充好】后会向server发TCP连接建立请求，client阻塞在这，server收到信息解除阻塞，返回一个新的值，即connection socket，在socket表中填充了socket，双方的IP和port，当server返回连接确认信息后，client也解除阻塞，这样就真正建立起了连接

close后，对应表项就会被删除

多个进程可以使用同一个端口，如welcome socket和connection socket使用的都是80端口

一个进程监听端口，经验告诉我们，如果多次启动一个进程会报错：“Address already in use!"。这是由于bind函数导致的，由于该端口号已经被第一个进程监听了。有哪些方法可以实现多个进程监听同一个端口呢？

fork：
只要在绑定端口号（bind函数）之后，监听端口号之前（listen函数），用fork（）函数生成子进程，这样子进程就可以克隆父进程，达到监听同一个端口的目的，而且还相互竞争，提高程序效率。

main的参数传入服务器的域名和port

这里没有bind，是OS隐式bind，随机选取一个暂时没有用到的端口号bind，所以上面的sockaddr_in中代表的是服务器的端节点IP+port

cad存放client的端节点，sad存放自己的

main的参数只需传入自己的port即可

中间省略了将clientSentence转换成全部大写的并存储在capitalizedSentence里面的代码【这个服务器执行的是将client传入的句子转换成大写返回的过程】

htons是将整型变量从主机字节顺序转变成网络字节顺序，就是整数在地址空间存储方式变为高位字节存放在内存的低地址处。

网络字节顺序是TCP/IP中规定好的一种数据表示格式，它与具体的CPU类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解释，网络字节顺序采用big-endian排序方式。

listen是把在为一个client服务的过程中又来了一个请求，那么把新的加到队列中，下次循环就从队列中取出一个服务，队列的长度为10 ，超过10就拒绝服务

2.9 UDP socket

UDP的PDU为数据报datagram，IP的无连接也叫datagram，因此需要结合上下文理解具体指哪个

client同样是隐式bind

也没有welcome和connection之分

2.10 小结

执行的是将client传入的句子转换成大写返回的过程*】

htons是将整型变量从主机字节顺序转变成网络字节顺序，就是整数在地址空间存储方式变为高位字节存放在内存的低地址处。

网络字节顺序是TCP/IP中规定好的一种数据表示格式，它与具体的CPU类型、操作系统等无关，从而可以保证数据在不同主机之间传输时能够被正确解释，网络字节顺序采用big-endian排序方式。

2.9 UDP socket

[外链图片转存中…(img-66vvw92w-1656228938930)]

UDP的PDU为数据报datagram，IP的无连接也叫datagram，因此需要结合上下文理解具体指哪个

client同样是隐式bind

[外链图片转存中…(img-ko3vz96F-1656228938931)]

也没有welcome和connection之分

[外链图片转存中…(img-V3qttUAn-1656228938931)]

[外链图片转存中…(img-ShC4wOFs-1656228938932)]

[外链图片转存中…(img-Z2OMwAVY-1656228938933)]

[外链图片转存中…(img-EfFXzHra-1656228938933)]

2.10 小结

[外链图片转存中…(img-NHz5v25W-1656228938934)]

[外链图片转存中…(img-wQ0wTjnW-1656228938934)]