1.linux下无线网卡的配置
命令 | 注释 |
---|---|
iw dev | ##查看设备 |
ip link show wlp0s20f0u2 | ##显示设备信息 |
ip link set wlp0s20f0u2 up | ##设备开启 |
iw wlp0s20f0u2 scan | grep SSID |
wpa_supplicant -B -i wlp0s20f0u2 -c<(wpa_passphrase “pierce34” “lj110110”) | ##绑定wifi |
dhclient wlp0s20f0u2 | ###启动 |
ip link show wlp0s20f0u2 | ##显示设备信息 |
ping www.baidu.com | 测试1 |
进入网站 | 测试2 |
2.TCP&UDP
2.1TCP
***传输控制协议(TCP,Transmission Control Protocol)***:是一种面向连接的、可靠的、基于字节流的传输层通信协议,由IETF的RFC 793 [1] 定义。
TCP旨在适应支持多网络应用的分层协议层次结构。 连接到不同但互连的计算机通信网络的主计算机中的成对进程之间依靠TCP提供可靠的通信服务。TCP假设它可以从较低级别的协议获得简单的,可能不可靠的数据报服务。 原则上,TCP应该能够在从硬线连接到分组交换或电路交换网络的各种通信系统之上操作。
2.1.1 tcp协议分层
TCP/IP协议族按照层次由上到下,层层包装。
应用层:向用户提供一组常用的应用程序,比如电子邮件、文件传输访问、远程登录等。远程登录TELNET使用TELNET协议提供在网络其它主机上注册的接口。TELNET会话提供了基于字符的虚拟终端。文件传输访问FTP使用FTP协议来提供网络内机器间的文件拷贝功能。
传输层:提供应用程序间的通信。其功能包括:一、格式化信息流;二、提供可靠传输。为实现后者,传输层协议规定接收端必须发回确认,并且假如分组丢失,必须重新发送。
网络层 :负责相邻计算机之间的通信。其功能包括三方面。
一、处理来自传输层的分组发送请求,收到请求后,将分组装入IP数据报,填充报头,选择去往信宿机的路径,然后将数据报发往适当的网络接口。
二、处理输入数据报:首先检查其合法性,然后进行寻径–假如该数据报已到达信宿机,则去掉报头,将剩下部分交给适当的传输协议;假如该数据报尚未到达信宿,则转发该数据报。
三、处理路径、流控、拥塞等问题。
网络接口层:这是TCP/IP软件的最低层,负责接收IP数据报并通过网络发送之,或者从网络上接收物理帧,抽出IP数据报,交给IP层。
TCP/IP:意味着 TCP 和 IP 在一起协同工作。
TCP 负责应用软件(比如你的浏览器)和网络软件之间的通信。
IP 负责计算机之间的通信。
TCP 负责将数据分割并装入 IP 包,然后在它们到达的时候重新组合它们。
IP 负责将包发送至接受者。
![](/qrcode.jpg)
2.1.2 tcp报文格式
理解
16位源端口号:16位的源端口中包含初始化通信的端口。源端口和源IP地址的作用是标识报文的返回地址。
16位目的端口号:16位的目的端口域定义传输的目的。这个端口指明报文接收计算机上的应用程序地址接口。
32位序号:32位的序列号由接收端计算机使用,重新分段的报文成最初形式。当SYN出现,序列码实际上是初始序列码(Initial Sequence Number,ISN),而第一个数据字节是ISN+1。这个序列号(序列码)可用来补偿传输中的不一致。
32位确认序号:32位的序列号由接收端计算机使用,重组分段的报文成最初形式。如果设置了ACK控制位,这个值表示一个准备接收的包的序列码。
4位首部长度:4位包括TCP头大小,指示何处数据开始。
6位保留:6位值域,这些位必须是0。为了将来定义新的用途而保留。
标志:6位标志域。表示为:紧急标志、有意义的应答标志、推、重置连接标志、同步序列号标志、完成发送数据标志。按照顺序排列是:URG、ACK、PSH、RST、SYN、FIN。
16位窗口大小:用来表示想收到的每个TCP数据段的大小。TCP的流量控制由连接的每一端通过声明的窗口大小来提供。窗口大小为字节数,起始于确认序号字段指明的值,这个值是接收端正期望接收的字节。窗口大小是一个16字节字段,因而窗口大小最大为65535字节。
16位校验和:16位TCP头。源机器基于数据内容计算一个数值,收信息机要与源机器数值 结果完全一样,从而证明数据的有效性。检验和覆盖了整个的TCP报文段:这是一个强制性的字段,一定是由发送端计算和存储,并由接收端进行验证的。
16位紧急指针:指向后面是优先数据的字节,在URG标志设置了时才有效。如果URG标志没有被设置,紧急域作为填充。加快处理标示为紧急的数据段。
选项:长度不定,但长度必须为1个字节。如果没有选项就表示这个1字节的域等于0。
数据:该TCP协议包负载的数据.
在上述字段中,6位标志域的各个选项功能如下:
(1)序列号seq:占4个字节,用来标记数据段的顺序,TCP把连接中发送的所有数据字节都编上一个序号,第一个字节的编号由本地随机产生;给字节编上序号后,就给每一个报文段指派一个序号;序列号seq就是这个报文段中的第一个字节的数据编号。
(2)确认号ACK:占4个字节,期待收到对方下一个报文段的第一个数据字节的序号;序列号表示报文段携带数据的第一个字节的编号;而确认号指的是期望接收到下一个字节的编号;因此当前报文段最后一个字节的编号+1即为确认号。
(3)推标志PSH:。该标志置位时,接收端不将该数据进行队列处理,而是尽可能快地将数据转由应用处理。在处理Telnet或rlogin等交互模式的连接时,该标志总是置位的。
(4)复位标志RST:。用于复位相应的TCP连接。
(5)同步SYN:连接建立时用于同步序号。当SYN=1,ACK=0时表示:这是一个连接请求报文段。若同意连接,则在响应报文段中使得SYN=1,ACK=1。因此,SYN=1表示这是一个连接请求,或连接接受报文。SYN这个标志位只有在TCP建产连接时才会被置1,握手完成后SYN标志位被置0。
(6)终止FIN:用来释放一个连接。FIN=1表示:此报文段的发送方的数据已经发送完毕,并要求释放运输连接
注意:ACK、SYN和FIN这些大写的单词表示标志位,其值要么是1,要么是0;ack、seq小写的单词表示序号。
字段 | 含义 |
---|---|
URG | ##紧急指针是否有效。为1,表示某一位需要被优先处理 |
ACK | ##确认号是否有效,一般置为1。 |
PSH | ##提示接收端应用程序立即从TCP缓冲区把数据读走。 |
RST | ## 对方要求重新建立连接,复位。 |
SYN | ##请求建立连接,并在其序列号的字段进行序列号的初始值设定。建立连接,设置为1 |
FIN | ##希望断开连接。 |
## 2.1.3 三次握手过程理解
第一次握手:建立连接时,客户端发送syn包(syn=x)到服务器,并进入SYN_SENT状态,等待服务器确认;SYN:同步序列编号(Synchronize Sequence Numbers)。
第二次握手:服务器收到syn包,必须确认客户的SYN(ack=x+1),同时自己也发送一个SYN包(syn=y),即SYN+ACK包,此时服务器进入SYN_RECV状态;
第三次握手:客户端收到服务器的SYN+ACK包,向服务器发送确认包ACK(ack=y+1),此包发送完毕,客户端和服务器进入ESTABLISHED(TCP连接成功)状态,完成三次握手。
## 2.1.4四次挥手过程理解
1)客户端进程发出连接释放报文,并且停止发送数据。释放数据报文首部,FIN=1,其序列号为seq=u(等于前面已经传送过来的数据的最后一个字节的序号加1),此时,客户端进入FIN-WAIT-1(终止等待1)状态。 TCP规定,FIN报文段即使不携带数据,也要消耗一个序号。
2)服务器收到连接释放报文,发出确认报文,ACK=1,ack=u+1,并且带上自己的序列号seq=v,此时,服务端就进入了CLOSE-WAIT(关闭等待)状态。TCP服务器通知高层的应用进程,客户端向服务器的方向就释放了,这时候处于半关闭状态,即客户端已经没有数据要发送了,但是服务器若发送数据,客户端依然要接受。这个状态还要持续一段时间,也就是整个CLOSE-WAIT状态持续的时间。
3)客户端收到服务器的确认请求后,此时,客户端就进入FIN-WAIT-2(终止等待2)状态,等待服务器发送连接释放报文(在这之前还需要接受服务器发送的最后的数据)。
4)服务器将最后的数据发送完毕后,就向客户端发送连接释放报文,FIN=1,ack=u+1,由于在半关闭状态,服务器很可能又发送了一些数据,假定此时的序列号为seq=w,此时,服务器就进入了LAST-ACK(最后确认)状态,等待客户端的确认。
5)客户端收到服务器的连接释放报文后,必须发出确认,ACK=1,ack=w+1,而自己的序列号是seq=u+1,此时,客户端就进入了TIME-WAIT(时间等待)状态。注意此时TCP连接还没有释放,必须经过2∗∗MSL(最长报文段寿命)的时间后,当客户端撤销相应的TCB后,才进入CLOSED状态。
6)服务器只要收到了客户端发出的确认,立即进入CLOSED状态。同样,撤销TCB后,就结束了这次的TCP连接。可以看到,服务器结束TCP连接的时间要比客户端早一些。
2.1.5 常见面试题
【问题1】为什么连接的时候是三次握手,关闭的时候却是四次握手?
答:因为当Server端收到Client端的SYN连接请求报文后,可以直接发送SYN+ACK报文。其中ACK报文是用来应答的,SYN报文是用来同步的。但是关闭连接时,当Server端收到FIN报文时,很可能并不会立即关闭SOCKET,所以只能先回复一个ACK报文,告诉Client端,“你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。故需要四步握手。
【问题2】为什么TIME_WAIT状态需要经过2MSL(最大报文段生存时间)才能返回到CLOSE状态?
答:虽然按道理,四个报文都发送完毕,我们可以直接进入CLOSE状态了,但是我们必须假象网络是不可靠的,有可以最后一个ACK丢失。所以TIME_WAIT状态就是用来重发可能丢失的ACK报文。在Client发送出最后的ACK回复,但该ACK可能丢失。Server如果没有收到ACK,将不断重复发送FIN片段。所以Client不能立即关闭,它必须确认Server接收到了该ACK。Client会在发送出ACK之后进入到TIME_WAIT状态。Client会设置一个计时器,等待2MSL的时间。如果在该时间内再次收到FIN,那么Client会重发ACK并再次等待2MSL。所谓的2MSL是两倍的MSL(Maximum Segment Lifetime)。MSL指一个片段在网络中最大的存活时间,2MSL就是一个发送和一个回复所需的最大时间。如果直到2MSL,Client都没有再次收到FIN,那么Client推断ACK已经被成功接收,则结束TCP连接。
【问题3】为什么不能用两次握手进行连接?
答:3次握手完成两个重要的功能,既要双方做好发送数据的准备工作(双方都知道彼此已准备好),也要允许双方就初始序列号进行协商,这个序列号在握手过程中被发送和确认。
现在把三次握手改成仅需要两次握手,死锁是可能发生的。作为例子,考虑计算机S和C之间的通信,假定C给S发送一个连接请求分组,S收到了这个分组,并发 送了确认应答分组。按照两次握手的协定,S认为连接已经成功地建立了,可以开始发送数据分组。可是,C在S的应答分组在传输中被丢失的情况下,将不知道S 是否已准备好,不知道S建立什么样的序列号,C甚至怀疑S是否收到自己的连接请求分组。在这种情况下,C认为连接还未建立成功,将忽略S发来的任何数据分 组,只等待连接确认应答分组。而S在发出的分组超时后,重复发送同样的分组。这样就形成了死锁。
【问题4】如果已经建立了连接,但是客户端突然出现故障了怎么办?
TCP还设有一个保活计时器,显然,客户端如果出现故障,服务器不能一直等下去,白白浪费资源。服务器每收到一次客户端的请求后都会重新复位这个计时器,时间通常是设置为2小时,若两小时还没有收到客户端的任何数据,服务器就会发送一个探测报文段,以后每隔75秒钟发送一次。若一连发送10个探测报文仍然没反应,服务器就认为客户端出了故障,接着就关闭连接。
2.2 udp
UDP协议:即用户数据报协议(User Datagram Protocol),是一个简单的面向数据报的传输层协议。UDP协议只在IP数据报服务商增加了很少一点的功能,就是复用和分用,以及差错检测的功能。
UDP协议的主要特点:(1)无连接的:发送数据之前不需要建立连接,减少了开销和发送数据之前的时延。
(2)尽最大努力交付:不保证可靠的交付,主机不需要维持复杂的链接状态表。
(3)面向报文的:发送方的UDP对应用程序交下来的报文,在添加首部后就向下交付给IP层。既不拆分,也不合并,而是保留这些报文的边界,因此,应用程序需要选择合适的报文大小。
(4)没有拥塞控制。
(5)支持一对一、多对一和多对多的交互通信。
(6)首部开销小,只有8个字节。
2.2.1UDP报文格式
用户数据报UDP有两个字段:数据字段和首部字段。首部字段只有8个字节,如下图所示:
UDP首部由4各字段组成,各占两个字节:
源端口:在需要对方回信时使用,不需要时全为0。
目的端口:发送UDP数据报的目的地。
长度:UDP数据报的长度,最短为8个字节,只包含首部。
检验和:用于检验UDP数据报在传输过程中有没有出差错,有则丢弃。
2.3 TCP和UDP区别
2.3.1 基本区别:
1.基于连接与无连接
2.TCP要求系统资源较多,UDP较少;
3.UDP程序结构较简单
4.流模式(TCP)与数据报模式(UDP);
5.TCP保证数据正确性,UDP可能丢包
6.TCP保证数据顺序,UDP不保证
7.UDP应用场景:
(1)面向数据报方式
(2)网络数据大多为短消息
(3)拥有大量Client
(4)对数据安全性无特殊要求
.(5)网络负担非常重,但对响应速度要求高
2.3.2编程步骤:
1.TCP:
TCP编程的服务器端一般步骤是:
1、创建一个socket,用函数socket();
2、设置socket属性,用函数setsockopt(); * 可选
3、绑定IP地址、端口等信息到socket上,用函数bind();
4、开启监听,用函数listen();
5、接收客户端上来的连接,用函数accept();
6、收发数据,用函数send()和recv(),或者read()和write();
7、关闭网络连接;
8、关闭监听;
TCP编程的客户端一般步骤是:
1、创建一个socket,用函数socket();
2、设置socket属性,用函数setsockopt();* 可选
3、绑定IP地址、端口等信息到socket上,用函数bind();* 可选
4、设置要连接的对方的IP地址和端口等属性;
5、连接服务器,用函数connect();
6、收发数据,用函数send()和recv(),或者read()和write();
7、关闭网络连接;
2.UDP
与之对应的UDP编程步骤要简单许多,分别如下:
UDP编程的服务器端一般步骤是:
1、创建一个socket,用函数socket();
2、设置socket属性,用函数setsockopt();* 可选
3、绑定IP地址、端口等信息到socket上,用函数bind();
4、循环接收数据,用函数recvfrom();
5、关闭网络连接;
UDP编程的客户端一般步骤是:
1、创建一个socket,用函数socket();
2、设置socket属性,用函数setsockopt();* 可选
3、绑定IP地址、端口等信息到socket上,用函数bind();* 可选
4、设置对方的IP地址和端口等属性;
5、发送数据,用函数sendto();
6、关闭网络连接;
2.3.3 其他区别:
TCP和UDP是OSI模型中的运输层中的协议。TCP提供可靠的通信传输,而UDP则常被用于让广播和细节控制交给应用的通信传输。
TCP充分实现了数据传输时各种控制功能,可以进行丢包的重发控制,还可以对次序乱掉的分包进行顺序控制。而这些在UDP中都没有。此外,TCP作为一种面向有连接的协议,只有在确认通信对端存在时才会发送数据,从而可以控制通信流量的浪费。TCP通过检验和、序列号、确认应答、重发控制、连接管理以及窗口控制等机制实现可靠性传输。
UDP不提供复杂的控制机制,利用IP提供面向无连接的通信服务。并且它是将应用程序发来的数据在收到的那一刻,立刻按照原样发送到网络上的一种机制。即使是出现网络拥堵的情况下,UDP也无法进行流量控制等避免网络拥塞的行为。此外,传输途中如果出现了丢包,UDO也不负责重发。甚至当出现包的到达顺序乱掉时也没有纠正的功能。如果需要这些细节控制,那么不得不交给由采用UDO的应用程序去处理。换句话说,UDP将部分控制转移到应用程序去处理,自己却只提供作为传输层协议的最基本功能。UDP有点类似于用户说什么听什么的机制,但是需要用户充分考虑好上层协议类型并制作相应的应用程序。
2.3.4总结
1、TCP面向连接(如打电话要先拨号建立连接);UDP是无连接的,即发送数据之前不需要建立连接
2、TCP提供可靠的服务。也就是说,通过TCP连接传送的数据,无差错,不丢失,不重复,且按序到达;UDP尽最大努力交付,即不保 证可靠交付
3、TCP面向字节流,实际上是TCP把数据看成一连串无结构的字节流;UDP是面向报文的
UDP没有拥塞控制,因此网络出现拥塞不会使源主机的发送速率降低(对实时应用很有用,如IP电话,实时视频会议等)
4、每一条TCP连接只能是点到点的;UDP支持一对一,一对多,多对一和多对多的交互通信
5、TCP首部开销20字节;UDP的首部开销小,只有8个字节
6、TCP的逻辑通信信道是全双工的可靠信道,UDP则是不可靠信道
3.linux下常用的端口号及服务
端口号 | 命令 | 注释 |
---|---|---|
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) |