计算机网络-应用层

应用层

应用层协议原理

网络应用程序体系解构

应用程序体系结构: 由应用程序研发者设计规定了如何在各种端系统上组织该应用程序。在选择应用程序体系结构时，应用程序研发者很可能利用现代网络应用程序中所使用的两种主流体系结构之一:客户-服务器体系结构或对等(P2P)体系结构。
客户-服务器体系结构:打开的主机称为服务器，它服务于来自许多其他称为客户的主机的请求。

对等(P2P)体系结构: 应用程序在间断连接的主机对之间使用直接通信，这些主机对被称为对等方,在一个P2P文件共享应用中，尽管每个对等方都由于请求文件产生工作负载，但每个对等方通过向其他对等方分发文件也为系统增加服务能力。

进程通信

进程: 进行通行的是进程
在两个不同端系统上的进程，通过跨越计算机网络交换报文(message)而相互通信。发送进程生成并向网络中发送报文:接收进程接收这些报文并可能通过回送报文进行响应。
Web应用程序中，一个客户浏览器进程与一台Web服务器进程交换报文。在一个P2P文件共系统中，文件从一个对等方中的进程传输到另一个对等方中的进程。

客户和服务端进程

付于Web而言，浏览器是一个客户进程，Web服务器是一台服务器进程。
对于P2P文件共享，下载文件的对等方标识为客户，上载文件的对等方标识为服务器。
在一对进程之间的通信会话场景中，发起通信(即在该会话开始时发起与其他进程的联系)的进程被标识为客户，在会话开始时等待联系的进程是服务器。

进程和计算机网络之间的接口

多数应用程序是由通信进程对组成，每对中的两个进程互相发送报文。从一个进程向另一个进程发送的报文必须通过下面的网络。进程通过一个称为套接字的软件接口向网络发送报文和从网络接收报文。
套接字是同一台主机内应用层与运输层之间的接口。由于该套接字是建立网络应用程序的可编程接口，因此套接字也称为应用程序和网络之间的应用程序编程接口
套接字对运输层的控制是: 选择运输层协议，设定几个运输层参数

进程寻址

在一台主机上运行的进程为了向在另一台主机上运行的进程发送分组，接收进程需要有一个地址。为了标识该接收进程，需要定义两种信息:①主机的地址;②在目的主机中指定接收进程的标识符。

除了知道报文发送目的地的主机地址外，发送进程还必须指定运行在接收主机上的接收进程(更具体地说，接收套接字)

可供应用程序使用的传输服务

套接字是应用程序进程和运输层协议之间的接口。在发送端的应用程序将报文推进该套接字。在该套接字的另一侧，运输层协议负责从接收进程的套接字得到该报文。

可靠数据传输

确保由应用程序的一端发送的数据正确、完全地交付给该应用程序的另一端。如果一个协议提供了这样的确保数据交付服务，就认为提供了可靠数据传输
运输层协议能够潜在地向应用程序提供的一个重要服务是进程到进程的可靠数据传输。当一个运输协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据将能无差错地到达接收进程。
当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能到达不了接收进程。这可能能被容忍丢失的应用

吞吐量

沿着一条网络路径上的两个进程之间的通信会话场景中，可用吞吐量就是发送进程能够向接收进程交付比特的速率。其他会话将共享沿着该网络路径的带宽，并且因为这些会话将会到达和离开，该可用吞吐量将随时间波动
运输层协议能够以某种特定的速率提供确保的可用吞吐量。这种服务将在发送和接收进程之间提供机密性，以防该数据以某种方式在这两个进程之间被观察到 。运输协议还能提供除了机密性以外的其他安全性服务，包括数据完整性和端点鉴别

定时

运输层协议也能提供定时保证。

安全性

在发送主机中，运输协议能够加密由发送进程传输的所有数据，在接收主机中，运输层协议能够在将数据交付给接收进程之前解密这些数据

因特网提供的运输服务

TCP服务

在握手阶段后， 一个TCP连接就在两个进程的套接字之间建立了。这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发,通信进程能够依靠TCP无差错、按适当顺序交付所有发送的数据。当应用程序的一端将字节流传进套接字时，它能够依靠TCP将相同的字节流交付给接收方的套接字，而没有字节的丢失和冗余。
拥塞控制机制，当发送方和接收方的网络发生拥塞的时候，TCP的拥塞控制机制会抑制发送进程。
SSL（Secure Sockets Layer），即安全套接层，是一种安全协议，它为网络（如互联网）通信提供安全及数据完整性保障。SSL在传输层与应用层之间对网络连接进行加密。
SSL协议由两部分组成：SSL握手协议和SSL记录协议。
SSL握手协议：用于在客户端与服务器之间建立安全连接，并确定安全连接所使用的加密套件、加密算法和会话密钥等信息。在握手过程中，服务器会向客户端发送证书以证明其身份，客户端则会对证书进行验证。
SSL记录协议：用于对应用层数据进行封装，并通过SSL握手协议所建立的安全连接进行传输。在封装过程中，SSL记录协议会对数据进行加密、完整性校验和压缩等操作，以确保数据的机密性、完整性和可靠性
SSL 不是与 TCP 和 UDP 在相同层次 上的第三种因特网运输协议，而是一种对 TCP 的加强，这种强化是在应用层上实现的
SSL有它自己的套接字API，这类似于传统的TCP套接字API。当一个应用使用SSL时，发送进程向SSL套接字传递明文数据。在发送主机中的SSL则加密该数据并将加密的数据传递给 TCP 套接字。加密的数据经因特网传送到接收进程中的 TCP 套接字。该接收套接字将加密数据传递给 SSL ，由其进行解密。最后， SSL通过它的SSL套接字将明文数据传递给接收进程

UDP服务

UDP是无连接的，因此在两个进程通信前没有握手过程。UDP协议提供一种不可靠数据传送服务，也就是说，当进程将一个报文发送进UDP套接字时，UDP协议并不保证该报文将到达接收进程。不仅如此，到达接收进程的报文也可能是乱序到达的。
UDP 没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层网络层注入数据。实际端到端吞吐量可能小于该速率，这可能具因为中间链路的带密受限或因为拥塞而浩成的

因特网运输协议所不提供的服务

应用层协议

应用层协议: 定义了在运行在不同端系统上的应用程序进程如何相互传递报文。

1. 交换的报文类型，例如请求报文和响应报文。
2. 各种报文类型的语法，如报文中的各个字段及这些字段是如何描述的。
3. 字段的语义，即这些字段中的信息的含义。
4. 确定一个进程何时以及如何发送报文，对报文进行响应的规则

web和Http

HTTP概况

HTT定义了web客户端向web服务器请求web页面的方式，以及服务器向客户传送Web页面的方式。

HTTP是使用TCP作为支撑运输协议。一旦连接建立该浏览器和服务器进程就可以通过套接字接口访问TCP。
客户端的套接字接口是客户进程与TCP连接之间的门，在服务器端的套接字接口则是服务器进程与TCP连接
服务器从它的套接接口接收 HTTP请求报文和向它的套接字接口发送 HTTP 响应报文。客户向它的套接字接口发送HTTP请求报文并从它的套接字接口接收HTTP响应报文。一旦客户向它的套接字接口发送了一个请求报文，该报文就脱离了客户控制并进入TCP的控制。
HTTP无状态协议是指协议对于事务处理没有记忆能力。这意味着每次HTTP请求都是独立的，服务器不会保留先前的请求信息，也不会将先前的请求与当前的请求关联起来。
服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息。假如某个特定的客户在短短的几秒内两次请求同一个对象，服务器并不会因为刚刚为该客户提供了该对象就不再做出反应，而是重新发送该对象，就像服务器已经完全忘记不久之前所做过的事一样。因为HTTP服务器并不保存关于客户的任何信息，所以HTTP是一个无状态协议

非持续连接和持续连接

非持续连接: HTTP请求报文和响应报文通过同一个TCP连接发送和接收。
持续连接: 非持续连接的相反形式。HTTP请求报文和响应报文通过不同的TCP连接发送和接收。

采用非持续连接的HTTP

往返时间(RRT): 从发送方发送数据开始，到发送方收到来自接收方的确认（通常是一个ACK报文），总共经历的时间。这个时间包括了数据在传输路径上的所有延迟，比如网络设备的处理延迟、排队延迟、传输延迟（光速限制）以及传播延迟（信号在介质中传播所需的时间）。
缺点

1. 必须为每一个请求的对象建立和维护一个全新的连接，对于每个这样的连接，在客户和服务器中都要分配TCP的缓冲区和保持TCP变量这给Web服务器带来了严重的负担。
2. 每一个对象经受两倍RTT的交付时延即一个RTT用于创建 TCP，另一个RTT用于请求和接收一个对象。

采用持续连接的HTTP

在采用HTTP1.1持续连接的情况下，服务器在发送响应后保持该TCP连接打开。在相同的客户与服务器之间，后续的请求和响应报文能够通过相同的连接进行传送。

web缓存

web缓存是代理服务器。当Web客户端（如Web浏览器）请求一个资源时，它会首先检查本地缓存中是否已有该资源的副本。如果找到，它会直接使用缓存的版本而不是从原始服务器重新下载。能够代表初始Web服务器来满足HTTP请求的网络实体。
Web缓存器有自己的磁盘存储空间，并在存储空间中保存最近请求过的对象的副本。
可以配置用户的浏览器，使得用户的所有HTTP请求首先指向 Web 缓存器。一旦某浏览器被配置，每个对某对象的浏览器请求首先被定向到该Web缓存器。
Web缓存器可以大大减少对客户请求的响应时间，特别是当客户与初始服务器之间的瓶颈带宽远低于客户与Web缓存器之间的瓶颈带宽时.如果用户所请求的对象在Web缓存器上，则Web缓存器可以迅速将该对象交付给用户

步骤

1. 浏览器创建一个到Web缓存器的TCP连接，并向Web缓存器中的对象发送一个HTTP请求。
2. Web缓存器进行检查，看看本地是否存储了该对象副本。如果有，Web缓存器就向客户浏览器用 HTTP响应报文返回该对象。
3. 如果Web缓存器中没有该对象，它就打开一个与该对象的初始服务器(即www.someschool.edu)的TCP连接。Web 缓存器则在这个缓存器到服务器的TCP 连接上发送一个对该对象的HTTP请求。在收到该请求后，初始服务器向该Web缓存器发送具有该对象的 HTTP 响应。
4. 当Web 缓存器接收到该对象时，它在本地存储空间存储一份副本，并向客户的浏览器用HTTP响应报文发送该副本(通过现有的客户浏览器和Web缓存器之间的TCP连接)。

因特网中的电子邮件

SMTP 使用TCP进行可靠数据传输服务，从发送方的邮件服务器向接收方的邮件服务器发送邮件。
运行在发送方邮件服务器的客户端和运行在接收方邮件服务器的服务器端每台邮件服务器上既运行SMTP的客户端也运行SMTP的服务器端。当一个邮件服务器向其他邮件服务器发送邮件时，它就表现为SMTP的客户:当邮件服务器从其他邮件服务器上接收邮件时，它就表现为一个 SMTP的服务器。

SMTP

步骤

1. Alice 调用她的邮件代理程序并提供Bob的邮件地址(例如 bob@someschool.edu),撰写报文，然后指示用户代理发送该报文。
2. Alice的用户代理把报文发给她的邮件服务器，在那里该报文被放在报文队列中。
3. 运行在Alice的邮件服务器上的SMTP 客户端发现了报文队列中的这个报文，它就创建一个到运行在Bob的邮件服务器上的SMTP服务器的TCP连接。
4. 在经过一些初始SMTP握手后，SMTP客户通过该TCP连接发送Alice的报文。
5. 在Bob的邮件服务器上，SMTP的服务器端接收该报文。Bob的邮件服务器然后将该报文放入Bob的邮箱中。
6. 在Bob方便的时候，他调用用户代理阅读该报文。
   

SMTP用的是持续连接:如果发送邮件服务器有几个报文发往同一个接收邮件服务器，它可以通过同一个TCP连接发送这些所有的报文。对每个报文，该客户用一个新的MAILFROM:crepes.开始，用一个独立的句点指示该邮件的结束，并且仅当所有邮件发送完后才发送 OUIT。

和http的对比

HTTP主要是一个拉协议(pullprotocol)即在方便的时候，某些人在 Web服务器上装载信息，用户使用HTTP从该服务器拉取这些信息
SMTP基本上是一个推协议，即发送邮件服务器把文件推向接收邮件服务器。

邮件访问协议

难题是： Bob的用户代理不能使用SMTP得到报文，因为取报文是一个拉操作，而SMTP协议是一个推协议。
解决这个问题的协议有: POP3, IMAP和HTTP

POP3

POP3协议默认端口为110，默认传输协议为TCP，适用的构架结构为C/S，访问模式为离线访问。POP3协议规定怎样将个人计算机连接到Internet的邮件服务器和下载电子邮件，是因特网电子邮件的第一个离线协议标准。
当用户代理(客户)打开了一个到邮件服务器(服务器)端口110上的TCP连接后，POP3就开始工作了。随着建立TCP连接，POP3按照三个阶段进行工作:特许、事务处理以及更新。在第一个阶段即特许阶段，用户代理发送(以明文形式)用户名和口令以鉴别用户。在第二个阶段即事务处理阶段，用户代理取回报文;同时在这个阶段用户代理还能进行如下操作，对报文做删除标记，取消报文删除标记，以及获取邮件的统计信息。在第三个阶段即更新阶段，它出现在客户发出了quit命令之后，目的是结束该POP3会话;这时，该邮件服务器删除那些被标记为删除的报文。

IMAP

IMAP是一个双向的通信协议，允许用户在邮件服务器上直接管理邮件，而不仅仅是下载邮件到本地设备。
IMAP服务器把每个报文与一个文件夹联系起来;当报文第一次到达服务器时，它与收件人的INBOX文件夹相关联。收件人则能够把邮件移到一个新的、用户创建的文件夹中，阅读邮件，删除邮件等。IMAP协议为用户提供了创建文件夹以及将邮件从一个文件夹移动到另一个文件夹的命令。IMAP还为用户提供了在远程文件夹中查询邮件的命令，按指定条件去查询匹配的邮件。值得注意的是，与POP3不同，IMAP服务器维护了IMAP会话的用户状态信息，例如，文件夹的名字以及哪些报文与哪些文件夹相关联。IMAP的另一个重要特性是它具有允许用户代理获取报文某些部分的命令。
IMAP是互联网消息访问协议，它用于在客户端（如电子邮件客户端软件或移动设备）和邮件服务器之间访问和管理电子邮件。与POP3不同，IMAP是一个双向的通信协议，允许用户在邮件服务器上直接管理邮件，而不仅仅是下载邮件到本地设备。
IMAP协议的主要特点包括：
双向通信：IMAP允许客户端和服务器之间进行双向通信，因此客户端可以实时查看服务器上的邮件状态（如新邮件、已读/未读状态等）。
邮件同步：由于IMAP在服务器上管理邮件，因此无论用户从哪个设备登录，他们都可以看到相同的邮件列表和状态。这意味着用户可以在多个设备之间无缝切换，而无需担心邮件同步问题。
文件夹支持：IMAP支持在服务器上创建、重命名和删除文件夹（通常称为“邮箱”或“标签”），以及在这些文件夹之间移动邮件。
搜索和排序：IMAP提供了强大的搜索和排序功能，允许用户根据各种条件（如发件人、主题、日期等）快速找到邮件。
离线访问：虽然IMAP主要是为在线访问设计的，但许多电子邮件客户端也支持IMAP的离线访问模式。这意味着用户可以在没有网络连接的情况下查看和编辑邮件，并在稍后同步到服务器。
安全性：IMAP支持通过SSL/TLS加密连接，以确保数据传输的安全性。
IMAP的默认端口通常为143（未加密）或993（SSL/TLS加密）。IMAP协议通常与SMTP（Simple Mail Transfer Protocol，简单邮件传输协议）一起使用，SMTP用于从客户端向服务器发送邮件。

DNS:因特网中的目录服务

DNS提供的服务

域名系统: 一个由分层的DNS服务器实现的分布式数据库,一个使得主机能够查询分布式数据库的应用层协议。
DNS是应用层协议，使用客户端服务器模式运行在通信的端系统之间。在通信的端系统之间通过下面的端到端运输协议来传输DNS报文。
DNS通常是有其他应用层协议所使用的。将用户提供的主机名解析为IP地址
使用户的主机能够将一个HTTP请求报文发送到Web服务器www.someschool.edu，该用户主机必须获得www.someschool.edu的IP地址。其做法如下。

1. 同一台用户主机上运行着 DNS 应用的客户端。
2. 浏览器从上述URL中抽取出主机名www.someschool.edu，并将这台主机名传给DNS 应用的客户端。
3. DNS客户向DNS服务器发送一个包含主机名的请求。
4. DNS客户最终会收到一份回答报文，其中含有对应于该主机名的地址。
5. 一旦浏览器接收到来自DNS的该IP地址，它能够向位于该IP地址80端口的HTTP 服务器进程发起一个TCP 连接。
   主机别名: 有着复杂主机名的主机能过拥有一个或者多个别名。
   邮件服务器别名: 允许一个公司的邮件服务器和Web服务器使用相同(别名化的)的主机名;
   负载分配： DNS也用于在冗余的服务器(如冗余的Web服务器等)之间进行负载分配

DNS工作机理概述

分布式，层次数据库

为了处理扩展性问题， DNS 使用了大量的 DNS 服务器 ，它们以层次方式组织，并且分布在全世界范围内 。 没有一台 DNS 服务器拥有因特网上所有主机的映射 。 相反、这些映射分布在所有的 DNS 服务器上 。

大致来说，有三种类型的dns服务器。根dns服务器，顶级域dns，权威dns服务器
顶级域DNS服务器: 对于每个顶级域(如com、org、net.edu和gov) 和所有国家的顶级域(如uk.fr.jp) ，都有TLD服务器(或服务器集群)。
权威DNS服务器: 在因特网上具有公共可访问主机(如Web服务器和邮件服务器)的每个组织机构必须提供公共可访问的DNS记录,这些记录将这些主机的名字映射为IP地址。一个组织机构的权威DNS服务器收藏了这些DNS记录。一个组织机构能够选择实现它自己的权威 DNS 服务器以保存这些记录
本地DNS服务器:并不属于该服务器的层次结构。每个ISP(如一个居民区的lSP或一个机构的ISP)都有一台本地DNS服务器(也叫默认名字服务器)。当主机与某个ISP连接时，该ISP提供一台主机的IP地址，该主机具有一台或多台其本地 DNS 服务器的IP地址

DNS缓存

DNS缓存：为了改善时延性能并减少在因特网上到处传输的DNS报文数量。
一个请求链中，当某DNS服务器接收一个DNS回答(例如，包含某主机名到IP地址的映射)时，它能将映射
缓存在本地存储器中。

DNS记录和报文

实现DNS分布式数据库的所有DNS服务器存储了资源记录。RR提供了主机到IP地址的映射。

(Name, Value, Type, TTL)

Type: A Name是主机名，Value是主机对应的IP地址。
Type: NS Name是域，Value是知道主机ip的权威DNS服务器主机名。
Type: CNAME Value是别名为Name的主机对应的规范主机名
Type: MX Value是别名为Name的邮件服务器的规范主机名。

DNS报文

在DNS数据库中插入记录

确定要插入的记录类型，确定要插入的记录类型，确定要插入的记录类型，确定要插入的记录类型，确定要插入的记录类型，确定要插入的记录类型，确定要插入的记录类型

P2P文件分发

使用P2P体系结构，对总是打开的基础设施服务器有最小的(或者没有)依赖。与之相反，成对间歇连接的主机(称为对等方)彼此直接通信。这些对等方并不为服务提供商所拥有，而是受用户控制的桌面计算机和膝上计算机。

P2P体系结构的拓展性

BitTorrent

最稀缺优先: 针对她没有的块在她的邻居中决最稀缺的块(最稀缺的块就是那些在她的邻居中副本数量最少的块)，并首先请求那些稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是(大致地)均衡每个块洪流中的副本数量。
分布式散列表：一种简单的数据库，其数据库记录分布在一个P2P系统的多个对等方上。

视频流和内容分发网

因特网视频

流式存储视频应用中，基础的媒体是预先录制好的视频。

HTTP流和DASH

在http流中，视频只是存储在http服务器中作为一个普通的文件。每个文件都有一个url。当用户要看该视频时，客户与服务器创建一个TCP连接并发送对该URL的HTTPGET请求。服务器则以底层网络协议和流量条件允许的尽可能快的速率，在一个HTTP响应报文中发送该视频文件。
在客户一侧，字节被收集在客户应用缓存中。一旦该缓存中的字节数量超过预先设定的门限，客户应用程序就开始播放，特别是，流式视频应用程序周期性地从客户应用程序缓存中抓取帧，对这些帧解压缩并且在用户屏幕上展现因此，流式视频应用接收到视频就进行播放，同时缓存该视频后面部分的帧。
DASH(经HTTP的动态适应流): 视频编码为几个不同的版本，其中每个版本具有不同的比特率，对于不同的质量水平，客户自然的选择来自高速率版本的快，当可用带宽流量较低的时候，客户自然而然的选择低速率板块的块。
DASH 允许客户使用不同的以太网接入速率流式播放具有不同编码速率的视频。使用低速3G连接的客户能够接收一个低比特率(和低质量)的版本，使用光纤连接的客户能够接收高质量的版本。如果端到端带宽在会话过程中改变的话，DASH允许客户适应可用带宽。
使用DASH后，每个视频版本存储在HTTP服务器中，每个版本都有一个不同的URL。HTTP服务器也有一个告示文件(manifestfle)，为每个版本提供了一个 URL 及其比特率。客户首先请求该告示文件并且得知各种各样的版本。然后客户通过在HTTPCET请求报文中对每块指定一个 URL和一个字节范围，一次选择一块。在下载块的同时，客户也测量接收带宽并运行一个速率决定算法来选择下次请求的块。自然地，如果客户缓存的视频很多，并且测量的接收带宽较高，它将选择一个高速率的版本。同样，如果客户缓存的视频很少，并且测量的接收带宽较低，它将选择一个低速率的版本。因此DASH允许客户自由地在不同的质量等级之间切换。

内容分发网

CDN(内容分发网): CDN管理分布在多个地理位置上的服务器，在它的服务器中存储视频(和其他类型的Web内容，包括文档、图片和音频)的副本，并且所有试图将每个用户请求定向到一个将提供最好的用户体验的CDN位置
专用CDN: 由内容提供商自己所拥有
第三方CDN: 多个内容提供商分发内容。
CDN:其目标是靠近端用户，通过减少端用户和CDN 集群之间(内容从这里收到)链路和路由器的数 量?从而改善了用户感受的时延和吞吐量
是过在少量关键位置建造大集群来邀请到ISP做客。不是将集群放接入ISP中，这些CDN通常将它们的集群放置在因特网交换点
许多CDN 没有将视频推人它们的集群，而是使用一种简单的拉策略:如果客户向一个未存储该视频的集群请求某视频，则该集群检索该视频(从某中心仓库或者从另一个集群)，向客户流式传输视频时的同时在本地存储一个副本。当某集群存储器变满时，它删除不经常请求的视频。

CDN操作

集群选择策略

集群选择策略动态地将客户定向到CDN中的某个服务器集群或数据中心的机制。
当从一个特殊的LDNS接收到一个DNS请求时，CDN 选择地理上最为接近的集群
为了基于当前流量条件为客户决定最好的集群，CDN能够对其集群和客户之间的时延和丢包性能执行周期性的实时测量。例如，CDN 能够让它的每个集群周期性地向位于全世界的所有LDNS发送探测分组(例如，ping报文或DNS请求)。这种方法的一个缺点是许多 LDNS 被配置为不会响应这些探测。

套接字编程

典型的网络应用是由一对程序(即客户程序和服务器程序)组成的它们位于两个不同的端系统中。当运行这两个程序时，创建了一个客户进程和一个服务器进程，同时它们通过从套接字读出和写入数据在彼此之间进行通信。开发者创建一个网络应用时，其主要任务就是编写客户程序和服务器程序的代码。
如果一个开发者编写客户程序的代码，另一个开发者编写服务器程序的代码，并且两者都完全遵从该RFC的各种规则，那么这两个程序将能够交互操作。
TCP是面向连接的，并且为两个端系统之间的数据流动提供可靠的字节流通道。UDP是无连接的，从一个端系统向另一个端系统发送独立的数据分组，不对交付提供任何保证。
前面也讲过当客户或服务器程序实现了一个由某RFC定义的协议时，它应当使用与该协议关联的周知端口号;与之相反，当研发一个专用应用程序时，研发者必须注意避免使用这些周知端口号。

UDP套接字编程

运行在不同机器上的进程彼此通过向套接字发送报文来进行通信
在发送进程能够讲数据分组退出套接字之前，需要将目的地址附着在该分组上，在该分组传过发送方的套接字之后，因特网使用该部米地址通过英特网为该分组选路到接收进程中的套接字。当分组接受到套接字的时候，接收进程需要将套接字取出分组，然后检查分组中的套接字，当分组到达接受套接字之后采取适当的动作。
目的地址是由目的主机的P地址和目的地套接字的端口号组成的。发送方的源地址也是由源主机的正P地址和源套接字的端口号组成。将源地址附在分组之上通常并不是由UDP应用程序代码所为，而是由底层操作系统自动完成的。

当创建套接字时，我们并没有指定客户套接字的端口号;让操作系统加上端口号

TCP套接字编程

和udp不同，tcp是一个面向连接的协议。意味着客户端和服务器端开始互相发送数据之前，需要先握手创建一个tcp连接，tcp连接的一端和客户端套接字连接，另一端和服务器套接字相链接。当创建tcp链接的时候， 将客户端套接字和服务器套接字相连接。
客户端具有向服务器发送接触的任务，服务器能对客户的初始接触作出反应。
随着服务器进程的运行，客户进程能够向服务器发起一个tcp连接。这是由客户程序通过创建一个tcp套接字完成的。当创建tcp套接字的时候，指定了服务器主机的ip地址和套接字的端口号。生成套接字之后，该客户端发起了一个三次握手并创建服务器的一个tcp连接。

连接套接字: 针对客户进行连接的新生成的套接字。称为连接套接字。
客户套接字和服务其连接套接字直接通过一个管道连接。客户进程可以向他的套接字发送任何字节，并且tcp保证服务器进程能够按照发送的顺序接受(通过套接字)的每个字节

连接套接字和欢迎套接字在TCP/IP网络通信中扮演着不同的角色。
连接套接字：这是随后为与每个客户通信而生成的套接字。在TCP/IP通信中，当客户端尝试与服务器建立连接时，服务器会生成一个连接套接字来专门处理与该客户端的通信。客户端的客户套接字与服务器端的连接套接字直接提供一根管道连接，客户进程可以向它的套接字发送任意字节，并且这种通信是可靠服务。类似的，服务器进程也能通过连接套接字接收字节并能向其发送字节。
欢迎套接字：这是使用要与服务器通信的客户的起始接触点。在服务器开始监听来自客户端的连接请求时，它会创建一个欢迎套接字。这个套接字会持续监听来自客户端的连接请求，并在收到请求时创建新的连接套接字来处理与客户端的通信。
简单来说，欢迎套接字是服务器用来监听客户端连接请求的套接字，而连接套接字则是服务器为处理与特定客户端的通信而创建的。在TCP/IP通信中，一个服务器通常只有一个欢迎套接字，但可以有多个连接套接字，每个连接套接字都与一个特定的客户端通信