虽然说数字阅读填充碎片化时间，但是确实阅读纸质书更容易安静下来，之前看电子档的这本书只是囫囵吞枣，打算再看一次纸质书顺便把书后编程题做完去，否则只知道理论则百无一用是”书生”
一、进程通信
在操作系统的术语中，进行通信额实际上是进程(process)而不是程序。
一个进程可以被认为是运行在端系统中的一个程序。
当进程运行在相同的端系统时，他们使用进程间相互通信机制相互通信，该机制由端系统上的操作系统确定。
在两个不同端系统上的进程，通过跨越计算机网络交换报文(message)而相互通信。
1.1、客户和服务器进程
在给定的一对进程的通信会话场景中，发起通信（即在该会话开始时发起与其他进程的联系）的进程被标识为客户，在会话开始时等待联系的进程是服务器。
1.2、进程与计算机网络之间的接口
进程通过一个称为“套接字（socket）”的软件接口向网络发送报文和从网络接收报文。
套接字也被称为应用程序和网络之间的应用程序编程接口（Application programing interface，API）。
1.3、运输层可以提供的四大方面服务
①可靠数据传输（reliable data transfer）：
当一个运输层协议提供这种服务时，发送进程只要将其数据传递进套接字，就可以完全相信该数据能够无差错地到达接收进程。当一个运输层协议不提供可靠数据传输时，由发送进程发送的某些数据可能不能够到达接收进程，这只适合容忍丢失的应用（loss-tolerant application）。
有很多多媒体应用就可以承受一定量的数据丢失（如音频、视频）。
②吞吐量：
运输层协议能够以某种特定的速率提供确保的可用吞吐量。
具有吞吐量要求的应用程序被称为带宽敏感的应用（bandwidth-sensitive application）。
带宽敏感的应用具有特定的吞吐量要求，而弹性应用（elastic application）能够根据情况或多或少地利用可供使用的吞吐量。
③定时：
运输层协议也能提供定时保证，如同具有吞吐量保证那样，定时保证能够以多种形式实现：比如，可以保证每个比特到达接收方的套接字不迟于100ms。
这种服务将对交互式实时应用程序有吸引力。
④安全性：
运输协议能够为应用程序提供一种或多种安全性服务，例如，有些发送主机中，运输协议可以加密由发送进程传输的所有数据；在接收主机中，运输层协议能够再将数据交付给接收进程之前解密这些数据。
运输协议还提供除了机密性意外的其他安全性服务，包括数据完整性和端点识别。
1.4、因特网提供的运输服务
因特网（一般的是TCP/IP网络）为应用程序提供两个运输层协议，即UDP和TCP。
当一个软件开发者为因特网创建一个新的应用时，首先要做出的决定是，选择UDP还是TCP。
①TCP服务
（1）面向连接的服务：
在应用层数据报文开始流动之前，其客户机程序和服务器程序之间互相交换运输层控制信息，完成握手阶段。这个过程可以让它们为大量分组的到来做好准备。
在握手阶段过后，一个TCP连接（TCP connection****）就在两个进程的套接字之间建立了。
这条连接是全双工的，即连接双方的进程可以在此连接上同时进行报文收发。
当应用程序结束报文发送时，必须拆除该连接。
（2）可靠的数据传送服务
（有拥塞控制机制）
②SSL（secure socket layer，安全套接字层）服务
无论TCP还是UDP都没有提供任何加密机制，因此，因特网界研制了TCP的加强版SSL。
SSL不仅可以做到传统的TCP所能够做到的一切，而且提供了加密、数据完整性和端点鉴别这些关键的进程到进程的安全性服务。
SSL有自己的套接字API，类似于传统的TCP套接字API。
发送进程（明文数据）→SSL套接字（加密后的数据）→TCP套接字（加密后的数据）→接收进程的TCP套接字（加密后的数据）→接收进程的SSL套接字（明文数据）→接收进程
③UDP服务
（1）UDP是一种不提供不必要服务的轻量级运输协议，它仅提供最小服务。
（2）UDP是无连接的，因此在两个进程通信前没有握手过程。
（3）UDP协议提供一种不可靠数据运输服务。
（4）UDP没有包括拥塞控制机制，所以UDP的发送端可以用它选定的任何速率向其下层（网络层）注入数据。
④因特网运输协议所不提供的服务
今天的因特网不能为应用提供任何定时或带宽保证。
时间敏感的应用通常是靠应用程序的设计，来最大程度的适应这种服务的缺乏。
因特网电话应用通常能够容忍某些数据丢失，但要求要达到一定的最小速率才能有效工作，所以通常会选择UDP来绕开TCP的拥塞控制机制。
1.5、应用层协议（application-layer protocol）
应用层协议定义了：
①交换的报文类型，如请求报文和响应报文。
②各种报文类型的语法，如报文中的各个字段和这些字段是如何描述的。
③字段的语义，即这些字段中包含的信息的含义。
④一个进程何时以及如何发送报文，对报文进行响应的规则。
应用层协议只是网络应用的非常重要的一部分
二、Web和HTTP
对于大多数用户来说，web最有吸引力的就是它的按需操作。
2.1、Http是一个无状态协议（stateless protocol）。
HTTP服务器向客户发送被请求的文件，而不存储任何关于该客户的状态信息，所以我们说HTTP是一个无状态协议（stateless protocol）。
2.2、非持续连接和持续连接
**非持续连接（non-persistant connection，又称“短连接”)**：每对请求/响应由一个单独的TCP连接发送。
**持续连接(persistant connection，又称“长连接”)**：所有的请求和响应都经一相同的TCP连接发送。
在默认配置下，大部分浏览器打开5~10个并行的TCP连接，而每条连接处理一个请求响应事务。
如果用户愿意，最大并行连接数可以设置为1，这样10条连接就会串行建立。
浏览器和web服务器建立一个TCP****连接时，会涉及到一个“三次握手”过程。
三次握手过程：
①客户向服务器发送一个小TCP报文段。
②服务器用一个小TCP报文段做出确认和响应。
③客户向服务器返回确认。
2.3、cookie
cookie的作用：cookie允许web服务器对用户进行跟踪，这样一来web站点便可以识别用户、限制用户的访问。
cookie 技术有四个组件：
①在HTTP响应报文中有一个cookie首部行。
②在HTTP请求报文中有一个cookie首部行。
③在用户端系统中保留有一个cookie文件，并由用户的浏览器进行管理。
④位于web站点的一个后端数据库。
2.4、Web缓存
Web缓存器带来的优点：
①Web缓存器可以大大减少一个机构的接入链路到因特网的通信量。
②Web缓存器能从整体上大大降低因特网上的Web流量，从而改善所有应用的性能。
（ISP可以通过内容分发网络（Content Distribution Network，CDN）技术来避免升级因特网链路的支出）
引入一个概念——缓存命中率：由一个缓存器所满足的请求占比率。（通常在0.2~0.7之间）
通过请求头的If-Modified-Since和响应头的Last-Modified实现
三、文件传输协议和电子邮件
3.1、文件传输协议：FTP
HTTP和FTP都是文本传输协议，他们有很多共同点，例如都运行在TCP上，但他们最显著的区别是FTP使用了两个并行的TCP连接，一个是控制连接，一个是数据连接。控制连接用于控制传输命令（put，get），数据连接用于传输文件数据。
电子邮件系统有 3 个主要组成部分： 用户代理、邮件服务器、简单邮件传输协议（SMTP）。
3.2、SMTP
SMTP是网络电子邮件应用的核心，一般不使用中间邮件服务器发送邮件，即使两个邮件服务器位于地球两端它使用TCP连接和ASCII编码(只能使用ASCII编码意味着传送二进制的多媒体文件会很麻烦)。为了描述SMTP的基本操作，我们假设ALice要给Bob发送一封简单的ASCII报文：
Alice调用他的用户代理程序并提供Bob的邮件地址，撰写报文，然后指示用户代理程序发送报文
Alice的用户代理程序把报文发送给它的邮件服务器，在那里该报文被放在报文队列中
运行在Alice邮件服务器上SMTP客户端发现报文队列中的报文，它就创建一个连接到Bob邮件服务器上的SMTP客户端的TCP连接
在经过初始的SMTP握手后，发送报文
Bob的邮件服务器接收报文后，将报文放在Bob的邮箱中
在Bob方便时，调用他的用户代理程序阅读报文
3.3、邮件访问协议
当我的邮件服务器有一封邮件，我如何把它取回到我的用户代理程序呢？
由于SMTP是一个推协议，我们只能用过引入其他的邮件访问协议来解决这个问题。
目前有一些流行的邮件访问协议第三版的邮局协议（POP3）、因特网邮件访问协议（IMAP）以及HTTP。
3.4、HTTP是拉协议，SMTP是推协议
四、DNS服务
4.1、分布式、层次数据库
DNS使用大量DNS服务器，以层次方式组织，分为3中类型：根DNS服务器、顶级域（TLD）DNS服务器、权威DNS服务器。
根DNS服务器：全球一共13个根DNS服务器。规定了合法域名.com .net .org等
顶级域服务器：负责维护顶级域名如com、org以及所有国家顶级域名cn、uk等
权威DNS服务器：在因特网上具有公共可访问主机（web服务器）的每个组织机构必须提供公共可访问的DNS记录，这些记录将这些主机名映射为IP地址。多数大学和大公司都实现或维护其权威DNS服务器。
4.2、DNS缓存
为了改善时延性能并减少在因特网上传输的DNS报文数量，DNS使用缓存技术。通常在本地服务器实现，可以缓存主机名/IP地址对，可以缓存TLD服务器地址，从而绕过根DNS服务器。
4.3、DNS记录和报文
资源记录是一个4元组：（Name，Value，Type，TTL）
TTL为该记录的生存时间，决定了资源记录应当从缓存中删除的时间。
Type=A，则Name是主机名，Value是该主机名对应的IP地址。
Type=NS，则Name是域，Value是如何获取该域中主机IP地址的权威DNS服务器的主机名。
Type=CNAME，则Value是别名为Name的主机对应的规范主机名。
Type=MX，则Value是别名为Name的邮件服务器对应的规范主机名。从而使得同一公司的邮件服务器和web服务器可以使用相同别名。
五、P2P文件分发和BitTorrent协议
BitTorrent是一种用于文件分发的流行P2P协议［Chao 2011］。用BitTorrent的术语来讲，参与一个特定文件分发的所有对等方的集合被称为一个洪流（torrent）。在一个洪流中的对等方彼此下载等长度的文件块（chunk），典型的块长度为256KB。当一个对等方首次加入一个洪流时，它没有块。随着时间的流逝，它累积了越来越多的块。当它下载块时，也为其他对等方上载了多个块。一旦某对等方获得了整个文件，它也许（自私地）离开洪流，或（大公无私地）留在该洪流中并继续向其他对等方上载块。同时，任何对等方可能在任何时候仅具有块的子集就离开该洪流，并在以后重新加入该洪流中。
每个洪流具有一个基础设施结点，称为追踪器（tracker）。当一个对等方加入某洪流时，它向追踪器注册自己，并周期性地通知追踪器它仍在该洪流中。以这种方式，追踪器跟踪正参与在洪流中的对等方。
最稀缺优先（rarest first）的技术
在决定请求哪些块的过程中，Alice使用一种称为最稀缺优先（rarest first）的技术。这种技术的思路是，针对她没有的块在她的邻居中决定最稀缺的块（最稀缺的块就是那些在她的邻居中副本数量最少的块），并首先请求那些最稀缺的块。这样，最稀缺块得到更为迅速的重新分发，其目标是（大致地）均衡每个块在洪流中的副本数量。
六、UDP和TCP套接字编程（基于python3)
由于书上是基于python2 的，所有做了些改变基于python3
https://github.com/Kit4y/Computer-Networking-Programming-Exercises
PS1、HTTP响应头和请求头信息对照表
HTTP Request Header 请求头
| Header | 解释 | 示例 |
|---|---|---|
| Accept | 指定客户端能够接收的内容类型 | Accept: text/plain, text/html |
| Accept-Charset | 浏览器可以接受的字符编码集。 | Accept-Charset: iso-8859-5 |
| Accept-Encoding | 指定浏览器可以支持的web服务器返回内容压缩编码类型。 | Accept-Encoding: compress, gzip |
| Accept-Language | 浏览器可接受的语言 | Accept-Language: en,zh |
| Accept-Ranges | 可以请求网页实体的一个或者多个子范围字段 | Accept-Ranges: bytes |
| Authorization | HTTP授权的授权证书 | Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Cache-Control | 指定请求和响应遵循的缓存机制 | Cache-Control: no-cache |
| Connection | 表示是否需要持久连接。（HTTP 1.1默认进行持久连接） | Connection: close |
| Cookie | HTTP请求发送时，会把保存在该请求域名下的所有cookie值一起发送给web服务器。 | Cookie: $Version=1; Skin=new; |
| Content-Length | 请求的内容长度 | Content-Length: 348 |
| Content-Type | 请求的与实体对应的MIME信息 | Content-Type: application/x-www-form-urlencoded |
| Date | 请求发送的日期和时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| Expect | 请求的特定的服务器行为 | Expect: 100-continue |
| From | 发出请求的用户的Email | From: user@email.com |
| Host | 指定请求的服务器的域名和端口号 | Host: www.zcmhi.com |
| If-Match | 只有请求内容与实体相匹配才有效 | If-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Modified-Since | 如果请求的部分在指定时间之后被修改则请求成功，未被修改则返回304代码 | If-Modified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| If-None-Match | 如果内容未改变返回304代码，参数为服务器先前发送的Etag，与服务器回应的Etag比较判断是否改变 | If-None-Match: “737060cd8c284d8af7ad3082f209582d” |
| If-Range | 如果实体未改变，服务器发送客户端丢失的部分，否则发送整个实体。参数也为Etag | If-Range: “737060cd8c284d8af7ad3082f209582d” |
| If-Unmodified-Since | 只在实体在指定时间之后未被修改才请求成功 | If-Unmodified-Since: Sat, 29 Oct 2010 19:43:31 GMT |
| Max-Forwards | 限制信息通过代理和网关传送的时间 | Max-Forwards: 10 |
| Pragma | 用来包含实现特定的指令 | Pragma: no-cache |
| Proxy-Authorization | 连接到代理的授权证书 | Proxy-Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== |
| Range | 只请求实体的一部分，指定范围 | Range: bytes=500-999 |
| Referer | 先前网页的地址，当前请求网页紧随其后,即来路 | Referer: http://www.zcmhi.com/archives/71.html |
| TE | 客户端愿意接受的传输编码，并通知服务器接受接受尾加头信息 | TE: trailers,deflate;q=0.5 |
| Upgrade | 向服务器指定某种传输协议以便服务器进行转换（如果支持） | Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 |
| User-Agent | User-Agent的内容包含发出请求的用户信息 | User-Agent: Mozilla/5.0 (Linux; X11) |
| Via | 通知中间网关或代理服务器地址，通信协议 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 关于消息实体的警告信息 | Warn: 199 Miscellaneous warning |
HTTP Responses Header 响应头
| Header | 解释 | 示例 |
|---|---|---|
| Accept-Ranges | 表明服务器是否支持指定范围请求及哪种类型的分段请求 | Accept-Ranges: bytes |
| Age | 从原始服务器到代理缓存形成的估算时间（以秒计，非负） | Age: 12 |
| Allow | 对某网络资源的有效的请求行为，不允许则返回405 | Allow: GET, HEAD |
| Cache-Control | 告诉所有的缓存机制是否可以缓存及哪种类型 | Cache-Control: no-cache |
| Content-Encoding | web服务器支持的返回内容压缩编码类型。 | Content-Encoding: gzip |
| Content-Language | 响应体的语言 | Content-Language: en,zh |
| Content-Length | 响应体的长度 | Content-Length: 348 |
| Content-Location | 请求资源可替代的备用的另一地址 | Content-Location: /index.htm |
| Content-MD5 | 返回资源的MD5校验值 | Content-MD5: Q2hlY2sgSW50ZWdyaXR5IQ== |
| Content-Range | 在整个返回体中本部分的字节位置 | Content-Range: bytes 21010-47021/47022 |
| Content-Type | 返回内容的MIME类型 | Content-Type: text/html; charset=utf-8 |
| Date | 原始服务器消息发出的时间 | Date: Tue, 15 Nov 2010 08:12:31 GMT |
| ETag | 请求变量的实体标签的当前值 | ETag: “737060cd8c284d8af7ad3082f209582d” |
| Expires | 响应过期的日期和时间 | Expires: Thu, 01 Dec 2010 16:00:00 GMT |
| Last-Modified | 请求资源的最后修改时间 | Last-Modified: Tue, 15 Nov 2010 12:45:26 GMT |
| Location | 用来重定向接收方到非请求URL的位置来完成请求或标识新的资源 | Location: http://www.zcmhi.com/archives/94.html |
| Pragma | 包括实现特定的指令，它可应用到响应链上的任何接收方 | Pragma: no-cache |
| Proxy-Authenticate | 它指出认证方案和可应用到代理的该URL上的参数 | Proxy-Authenticate: Basic |
| refresh | 应用于重定向或一个新的资源被创造，在5秒之后重定向（由网景提出，被大部分浏览器支持） | Refresh: 5; url=http://www.zcmhi.com/archives/94.html |
| Retry-After | 如果实体暂时不可取，通知客户端在指定时间之后再次尝试 | Retry-After: 120 |
| Server | web服务器软件名称 | Server: Apache/1.3.27 (Unix) (Red-Hat/Linux) |
| Set-Cookie | 设置Http Cookie | Set-Cookie: UserID=JohnDoe; Max-Age=3600; Version=1 |
| Trailer | 指出头域在分块传输编码的尾部存在 | Trailer: Max-Forwards |
| Transfer-Encoding | 文件传输编码 | Transfer-Encoding:chunked |
| Vary | 告诉下游代理是使用缓存响应还是从原始服务器请求 | Vary: * |
| Via | 告知代理客户端响应是通过哪里发送的 | Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1) |
| Warning | 警告实体可能存在的问题 | Warning: 199 Miscellaneous warning |
| WWW-Authenticate | 表明客户端请求实体应该使用的授权方案 | WWW-Authenticate: Basic |
PS2、HTTP状态码表
| 状态码 | 状态码英文名称 | 中文描述 |
|---|---|---|
| 100 | Continue | 继续。客户端应继续其请求 |
| 101 | Switching Protocols | 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议 |
| 200 | OK | 请求成功。一般用于GET与POST请求 |
| 201 | Created | 已创建。成功请求并创建了新的资源 |
| 202 | Accepted | 已接受。已经接受请求，但未处理完成 |
| 203 | Non-Authoritative Information | 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本 |
| 204 | No Content | 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档 |
| 205 | Reset Content | 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域 |
| 206 | Partial Content | 部分内容。服务器成功处理了部分GET请求 |
| 300 | Multiple Choices | 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择 |
| 301 | Moved Permanently | 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替 |
| 302 | Found | 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI |
| 303 | See Other | 查看其它地址。与301类似。使用GET和POST请求查看 |
| 304 | Not Modified | 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源 |
| 305 | Use Proxy | 使用代理。所请求的资源必须通过代理访问 |
| 306 | Unused | 已经被废弃的HTTP状态码 |
| 307 | Temporary Redirect | 临时重定向。与302类似。使用GET请求重定向 |
| 400 | Bad Request | 客户端请求的语法错误，服务器无法理解 |
| 401 | Unauthorized | 请求要求用户的身份认证 |
| 402 | Payment Required | 保留，将来使用 |
| 403 | Forbidden | 服务器理解请求客户端的请求，但是拒绝执行此请求 |
| 404 | Not Found | 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置”您所请求的资源无法找到”的个性页面 |
| 405 | Method Not Allowed | 客户端请求中的方法被禁止 |
| 406 | Not Acceptable | 服务器无法根据客户端请求的内容特性完成请求 |
| 407 | Proxy Authentication Required | 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权 |
| 408 | Request Time-out | 服务器等待客户端发送的请求时间过长，超时 |
| 409 | Conflict | 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突 |
| 410 | Gone | 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置 |
| 411 | Length Required | 服务器无法处理客户端发送的不带Content-Length的请求信息 |
| 412 | Precondition Failed | 客户端请求信息的先决条件错误 |
| 413 | Request Entity Too Large | 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息 |
| 414 | Request-URI Too Large | 请求的URI过长（URI通常为网址），服务器无法处理 |
| 415 | Unsupported Media Type | 服务器无法处理请求附带的媒体格式 |
| 416 | Requested range not satisfiable | 客户端请求的范围无效 |
| 417 | Expectation Failed | 服务器无法满足Expect的请求头信息 |
| 500 | Internal Server Error | 服务器内部错误，无法完成请求 |
| 501 | Not Implemented | 服务器不支持请求的功能，无法完成请求 |
| 502 | Bad Gateway | 充当网关或代理的服务器，从远端服务器接收到了一个无效的请求 |
| 503 | Service Unavailable | 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中 |
| 504 | Gateway Time-out | 充当网关或代理的服务器，未及时从远端服务器获取请求 |
| 505 | HTTP Version not supported | 服务器不支持请求的HTTP协议的版本，无法完成处理 |
P3、常见端口号参照表
| 端口号码 / 层 | 名称 | 注释 |
|---|---|---|
| 1 | tcpmux | TCP 端口服务多路复用 |
| 5 | rje | 远程作业入口 |
| 7 | echo | Echo 服务 |
| 9 | discard | 用于连接测试的空服务 |
| 11 | systat | 用于列举连接了的端口的系统状态 |
| 13 | daytime | 给请求主机发送日期和时间 |
| 17 | qotd | 给连接了的主机发送每日格言 |
| 18 | msp | 消息发送协议 |
| 19 | chargen | 字符生成服务；发送无止境的字符流 |
| 20 | ftp-data | FTP 数据端口 |
| 21 | ftp | 文件传输协议（FTP）端口；有时被文件服务协议（FSP）使用 |
| 22 | ssh | 安全 Shell（SSH）服务 |
| 23 | telnet | Telnet 服务 |
| 25 | smtp | 简单邮件传输协议（SMTP） |
| 37 | time | 时间协议 |
| 39 | rlp | 资源定位协议 |
| 42 | nameserver | 互联网名称服务 |
| 43 | nicname | WHOIS 目录服务 |
| 49 | tacacs | 用于基于 TCP/IP 验证和访问的终端访问控制器访问控制系统 |
| 50 | re-mail-ck | 远程邮件检查协议 |
| 53 | domain | 域名服务（如 BIND） |
| 63 | whois++ | WHOIS++，被扩展了的 WHOIS 服务 |
| 67 | bootps | 引导协议（BOOTP）服务；还被动态主机配置协议（DHCP）服务使用 |
| 68 | bootpc | Bootstrap（BOOTP）客户；还被动态主机配置协议（DHCP）客户使用 |
| 69 | tftp | 小文件传输协议（TFTP） |
| 70 | gopher | Gopher 互联网文档搜寻和检索 |
| 71 | netrjs-1 | 远程作业服务 |
| 72 | netrjs-2 | 远程作业服务 |
| 73 | netrjs-3 | 远程作业服务 |
| 73 | netrjs-4 | 远程作业服务 |
| 79 | finger | 用于用户联系信息的 Finger 服务 |
| 80 | http | 用于万维网（WWW）服务的超文本传输协议（HTTP） |
| 88 | kerberos | Kerberos 网络验证系统 |
| 95 | supdup | Telnet 协议扩展 |
| 101 | hostname | SRI-NIC 机器上的主机名服务 |
| 102 | iso-tsap | ISO 开发环境（ISODE）网络应用 |
| 105 | csnet-ns | 邮箱名称服务器；也被 CSO 名称服务器使用 |
| 107 | rtelnet | 远程 Telnet |
| 109 | pop2 | 邮局协议版本2 |
| 110 | pop3 | 邮局协议版本3 |
| 111 | sunrpc | 用于远程命令执行的远程过程调用（RPC）协议，被网络文件系统（NFS）使用 |
| 113 | auth | 验证和身份识别协议 |
| 115 | sftp | 安全文件传输协议（SFTP）服务 |
| 117 | uucp-path | Unix 到 Unix 复制协议（UUCP）路径服务 |
| 119 | nntp | 用于 USENET 讨论系统的网络新闻传输协议（NNTP） |
| 123 | ntp | 网络时间协议（NTP） |
| 137 | netbios-ns | 在红帽企业 Linux 中被 Samba 使用的 NETBIOS 名称服务 |
| 138 | netbios-dgm | 在红帽企业 Linux 中被 Samba 使用的 NETBIOS 数据报服务 |
| 139 | netbios-ssn | 在红帽企业 Linux 中被 Samba 使用的NET BIOS 会话服务 |
| 143 | imap | 互联网消息存取协议（IMAP） |
| 161 | snmp | 简单网络管理协议（SNMP） |
| 162 | snmptrap | SNMP 的陷阱 |
| 163 | cmip-man | 通用管理信息协议（CMIP） |
| 164 | cmip-agent | 通用管理信息协议（CMIP） |
| 174 | mailq | MAILQ |
| 177 | xdmcp | X 显示管理器控制协议 |
| 178 | nextstep | NeXTStep 窗口服务器 |
| 179 | bgp | 边界网络协议 |
| 191 | prospero | Cliffod Neuman 的 Prospero 服务 |
| 194 | irc | 互联网中继聊天（IRC） |
| 199 | smux | SNMP UNIX 多路复用 |
| 201 | at-rtmp | AppleTalk 选路 |
| 202 | at-nbp | AppleTalk 名称绑定 |
| 204 | at-echo | AppleTalk echo 服务 |
| 206 | at-zis | AppleTalk 区块信息 |
| 209 | qmtp | 快速邮件传输协议（QMTP） |
| 210 | z39.50 | NISO Z39.50 数据库 |
| 213 | ipx | 互联网络分组交换协议（IPX），被 Novell Netware 环境常用的数据报协议 |
| 220 | imap3 | 互联网消息存取协议版本3 |
| 245 | link | LINK |
| 347 | fatserv | Fatmen 服务器 |
| 363 | rsvp_tunnel | RSVP 隧道 |
| 369 | rpc2portmap | Coda 文件系统端口映射器 |
| 370 | codaauth2 | Coda 文件系统验证服务 |
| 372 | ulistproc | UNIX Listserv |
| 389 | ldap | 轻型目录存取协议（LDAP） |
| 427 | svrloc | 服务位置协议（SLP） |
| 434 | mobileip-agent | 可移互联网协议（IP）代理 |
| 435 | mobilip-mn | 可移互联网协议（IP）管理器 |
| 443 | https | 安全超文本传输协议（HTTP） |
| 444 | snpp | 小型网络分页协议 |
| 445 | microsoft-ds | 通过 TCP/IP 的服务器消息块（SMB） |
| 464 | kpasswd | Kerberos 口令和钥匙改换服务 |
| 468 | photuris | Photuris 会话钥匙管理协议 |
| 487 | saft | 简单不对称文件传输（SAFT）协议 |
| 488 | gss-http | 用于 HTTP 的通用安全服务（GSS） |
| 496 | pim-rp-disc | 用于协议独立的多址传播（PIM）服务的会合点发现（RP-DISC） |
| 500 | isakmp | 互联网安全关联和钥匙管理协议（ISAKMP） |
| 535 | iiop | 互联网内部对象请求代理协议（IIOP） |
| 538 | gdomap | GNUstep 分布式对象映射器（GDOMAP） |
| 546 | dhcpv6-client | 动态主机配置协议（DHCP）版本6客户 |
| 547 | dhcpv6-server | 动态主机配置协议（DHCP）版本6服务 |
| 554 | rtsp | 实时流播协议（RTSP） |
| 563 | nntps | 通过安全套接字层的网络新闻传输协议（NNTPS） |
| 565 | whoami | whoami |
| 587 | submission | 邮件消息提交代理（MSA） |
| 610 | npmp-local | 网络外设管理协议（NPMP）本地 / 分布式排队系统（DQS） |
| 611 | npmp-gui | 网络外设管理协议（NPMP）GUI / 分布式排队系统（DQS） |
| 612 | hmmp-ind | HMMP 指示 / DQS |
| 631 | ipp | 互联网打印协议（IPP） |
| 636 | ldaps | 通过安全套接字层的轻型目录访问协议（LDAPS） |
| 674 | acap | 应用程序配置存取协议（ACAP） |
| 694 | ha-cluster | 用于带有高可用性的群集的心跳服务 |
| 749 | kerberos-adm | Kerberos 版本5（v5）的“kadmin”数据库管理 |
| 750 | kerberos-iv | Kerberos 版本4（v4）服务 |
| 765 | webster | 网络词典 |
| 767 | phonebook | 网络电话簿 |
| 873 | rsync | rsync 文件传输服务 |
| 992 | telnets | 通过安全套接字层的 Telnet（TelnetS） |
| 993 | imaps | 通过安全套接字层的互联网消息存取协议（IMAPS） |
| 994 | ircs | 通过安全套接字层的互联网中继聊天（IRCS） |
| 995 | pop3s | 通过安全套接字层的邮局协议版本3（POPS3） |