思科人才孵化项目 Day6


思科孵化项目 Day6

TCP 的特性

  • TCP 提供一种面向连接的、可靠的字节流服务
  • 在一个 TCP 连接中,仅有两方进行彼此通信。广播和多播不能用于 TCP
  • TCP 使用校验和,确认和重传机制来保证可靠传输
  • TCP 给数据分节进行排序,并使用累积确认保证数据的顺序不变和非重复
  • TCP 使用滑动窗口机制来实现流量控制,通过动态改变窗口的大小进行拥塞控制

注意:TCP 并不能保证数据一定会被对方接收到,因为这是不可能的。TCP 能够做到的是,如果有可能,就把数据递送到接收方,否则就(通过放弃重传并且中断连接这一手段)通知用户。因此准确说 TCP 也不是 100% 可靠的协议,它所能提供的是数据的可靠递送或故障的可靠通知。

三次握手与四次挥手

所谓三次握手(Three-way Handshake),是指建立一个 TCP 连接时,需要客户端和服务器总共发送3个包。

三次握手的目的是连接服务器指定端口,建立 TCP 连接,并同步连接双方的序列号和确认号,交换 TCP 窗口大小信息。在 socket 编程中,客户端执行 connect() 时。将触发三次握手。

  • 第一次握手(SYN=1, seq=x):

    客户端发送一个 TCP 的 SYN 标志位置1的包,指明客户端打算连接的服务器的端口,以及初始序号 X,保存在包头的序列号(Sequence Number)字段里。

    发送完毕后,客户端进入 SYN_SEND 状态。

  • 第二次握手(SYN=1, ACK=1, seq=y, ACKnum=x+1):

    服务器发回确认包(ACK)应答。即 SYN 标志位和 ACK 标志位均为1。服务器端选择自己 ISN 序列号,放到 Seq 域里,同时将确认序号(Acknowledgement Number)设置为客户的 ISN 加1,即X+1。 发送完毕后,服务器端进入 SYN_RCVD 状态。

  • 第三次握手(ACK=1,ACKnum=y+1)

    客户端再次发送确认包(ACK),SYN 标志位为0,ACK 标志位为1,并且把服务器发来 ACK 的序号字段+1,放在确定字段中发送给对方,并且在数据段放写ISN的+1

    发送完毕后,客户端进入 ESTABLISHED 状态,当服务器端接收到这个包时,也进入 ESTABLISHED 状态,TCP 握手结束。

三次握手的过程的示意图如下:

three-way-handshake

TCP 的连接的拆除需要发送四个包,因此称为四次挥手(Four-way handshake),也叫做改进的三次握手。客户端或服务器均可主动发起挥手动作,在 socket 编程中,任何一方执行 close() 操作即可产生挥手操作。

  • 第一次挥手(FIN=1,seq=x)

    假设客户端想要关闭连接,客户端发送一个 FIN 标志位置为1的包,表示自己已经没有数据可以发送了,但是仍然可以接受数据。

    发送完毕后,客户端进入 FIN_WAIT_1 状态。

  • 第二次挥手(ACK=1,ACKnum=x+1)

    服务器端确认客户端的 FIN 包,发送一个确认包,表明自己接受到了客户端关闭连接的请求,但还没有准备好关闭连接。

    发送完毕后,服务器端进入 CLOSE_WAIT 状态,客户端接收到这个确认包之后,进入 FIN_WAIT_2 状态,等待服务器端关闭连接。

  • 第三次挥手(FIN=1,seq=y)

    服务器端准备好关闭连接时,向客户端发送结束连接请求,FIN 置为1。

    发送完毕后,服务器端进入 LAST_ACK 状态,等待来自客户端的最后一个ACK。

  • 第四次挥手(ACK=1,ACKnum=y+1)

    客户端接收到来自服务器端的关闭请求,发送一个确认包,并进入 TIME_WAIT状态,等待可能出现的要求重传的 ACK 包。

    服务器端接收到这个确认包之后,关闭连接,进入 CLOSED 状态。

    客户端等待了某个固定时间(两个最大段生命周期,2MSL,2 Maximum Segment Lifetime)之后,没有收到服务器端的 ACK ,认为服务器端已经正常关闭连接,于是自己也关闭连接,进入 CLOSED 状态。

四次挥手的示意图如下:

four-way-handshake

SYN攻击

  • 什么是 SYN 攻击(SYN Flood)?

    在三次握手过程中,服务器发送 SYN-ACK 之后,收到客户端的 ACK 之前的 TCP 连接称为半连接(half-open connect)。此时服务器处于 SYN_RCVD 状态。当收到 ACK 后,服务器才能转入 ESTABLISHED 状态.

    SYN 攻击指的是,攻击客户端在短时间内伪造大量不存在的IP地址,向服务器不断地发送SYN包,服务器回复确认包,并等待客户的确认。由于源地址是不存在的,服务器需要不断的重发直至超时,这些伪造的SYN包将长时间占用未连接队列,正常的SYN请求被丢弃,导致目标系统运行缓慢,严重者会引起网络堵塞甚至系统瘫痪。

    SYN 攻击是一种典型的 DoS/DDoS 攻击。

  • 如何检测 SYN 攻击?

    检测 SYN 攻击非常的方便,当你在服务器上看到大量的半连接状态时,特别是源IP地址是随机的,基本上可以断定这是一次SYN攻击。在 Linux/Unix 上可以使用系统自带的 netstats 命令来检测 SYN 攻击。

  • 如何防御 SYN 攻击?

    SYN攻击不能完全被阻止,除非将TCP协议重新设计。我们所做的是尽可能的减轻SYN攻击的危害,常见的防御 SYN 攻击的方法有如下几种:

    • 缩短超时(SYN Timeout)时间
    • 增加最大半连接数
    • 过滤网关防护
    • SYN cookies技术

TCP KeepAlive

TCP 的连接,实际上是一种纯软件层面的概念,在物理层面并没有“连接”这种概念。TCP 通信双方建立交互的连接,但是并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会。在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启等各种意外,当这些意外发生之后,这些 TCP 连接并未来得及正常释放,在软件层面上,连接的另一方并不知道对端的情况,它会一直维护这个连接,长时间的积累会导致非常多的半打开连接,造成端系统资源的消耗和浪费,为了解决这个问题,在传输层可以利用 TCP 的 KeepAlive 机制实现来实现。主流的操作系统基本都在内核里支持了这个特性。

TCP KeepAlive 的基本原理是,隔一段时间给连接对端发送一个探测包,如果收到对方回应的 ACK,则认为连接还是存活的,在超过一定重试次数之后还是没有收到对方的回应,则丢弃该 TCP 连接。

TCP-Keepalive-HOWTO 有对 TCP KeepAlive 特性的详细介绍,有兴趣的同学可以参考。这里主要说一下,TCP KeepAlive 的局限。首先 TCP KeepAlive 监测的方式是发送一个 probe 包,会给网络带来额外的流量,另外 TCP KeepAlive 只能在内核层级监测连接的存活与否,而连接的存活不一定代表服务的可用。例如当一个服务器 CPU 进程服务器占用达到 100%,已经卡死不能响应请求了,此时 TCP KeepAlive 依然会认为连接是存活的。因此 TCP KeepAlive 对于应用层程序的价值是相对较小的。需要做连接保活的应用层程序,例如 QQ,往往会在应用层实现自己的心跳功能。

参考资料

IP分片和TCP分段

最大传输单元 MTU(MaximumTransmission Unit)

以太网和802.3对数据帧的长度都有一个限制,其最大值分别是1500和1492个字节。链路层的这个特性称作MTU。不同类型的网络大多数都有一个上限。如果IP层有一个数据要传,且数据的长度比链路层的MTU还大,那么IP层就要进行分片(fragmentation),把数据报分成若干片,这样每一个分片都小于MTU。

把一份IP数据报进行分片以后,由到达目的端的IP层来进行重新组装,其目的是使分片和重新组装过程对运输层(TCP/UDP)是透明的。由于每一分片都是一个独立的包,当这些数据报的片到达目的端时有可能会失序,但是在IP首部中有足够的信息让接收端能正确组装这些数据报片

尽管IP分片过程看起来透明的,但有一点让人不想使用它:即使只丢失一片数据也要重新传整个数据报

why?因为IP层本身没有超时重传机制------由更高层(比如TCP)来负责超时和重传。当来自TCP报文段的某一片丢失后,TCP在超时后会重发整个TCP报文段,该报文段对应于一份IP数据报(而不是一个分片),没有办法只重传数据报中的一个数据分片。

使用UDP很容易导致IP分片,TCP试图避免IP分片。那么TCP是如何试图避免IP分片的呢?其实说白了,采用TCP协议进行数据传输是不会造成IP分片的,因为一旦TCP数据过大,超过了MSS,则在传输层会对TCP包进行分段(如何分,见下文!),自然到了IP层的数据报肯定不会超过MTU,当然也就不用分片了。而对于UDP数据报,如果UDP组成的IP数据报长度超过了1500,那么IP数据报显然就要进行分片,因为UDP不能像TCP一样自己进行分段

总结:UDP不会分段,就由我IP来分。TCP会分段,当然也就不用我IP来分了!

MSS(Maxitum SegmentSize)最大分段大小

是TCP协议里面的一个概念

MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值,这个值TCP协议在实现的时候往往用MTU值代替(需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes)所以往往MSS为1460。通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。

还有最后一个问题:TCP是如何实现分段的呢?其实TCP无所谓分段,因为每个TCP数据报在组成前其大小就已经被MSS限制了,所以TCP数据报的长度是不可能大于MSS的,当然由它形成的IP包的长度也就不会大于MTU,自然也就不用IP分片了

应用场景

避免 IPv4 分段:TCP MSS 用途及其工作原理

TCP 最大分段大小 (MSS) 定义主机希望在单个 TCP/IPv4 数据报中接受的最大数据量。此 TCP/IPv4 数据报可能会在 IPv4 层分段。MSS 值仅作为 TCP SYN 数据段中的一个 TCP 报头选项发送。TCP 连接的每一端都会向另一端报告其 MSS 值。与普遍看法相反的是,不会在主机之间协商 MSS 值。发送主机需要将单个 TCP 分段中的数据量限制为小于等于接收主机报告的 MSS 值。

最初,MSS 决定着接收站上分配用于存储单个 IPv4 数据报所含 TCP 数据的缓冲区的大小(大于等于 65496 字节)。MSS 是指 TCP 接收端愿意接受的最大数据分段 (chunk)。此 TCP 分段可以长达 64K(最大的 IPv4 数据报长度);要通过网络将其传输到接收主机,可以在 IPv4 层对其进行分段。在将完整的 TCP 分段传送至 TCP 层之前,接收主机会重组 IPv4 数据报。

下面的几个场景展示如何设置 MSS 值并将其用于限制 TCP 分段大小,从而限制 IPv4 数据报的大小。

方案 1 说明了 MSS 的最初实现方式。主机 A 的缓冲区为 16K,主机 B 的缓冲区为 8K。它们发送和接收各自的 MSS 值,并调整用于相互发送数据的发送 MSS。请注意,主机 A 和主机 B 必须将大于接口 MTU、但仍小于发送 MSS 的 IPv4 数据报分段,因为 TCP 堆栈可以将 16K 或 8K 字节的数据从堆栈向下传递到 IPv4。至于主机 B,可以对数据包执行两次分段,一次是为了在令牌环 LAN 上传输,另一次是为了在以太网 LAN 上传输。

场景 1

场景 1
  1. 主机 A 将其 MSS 值 16K 发送到主机 B。
  2. 主机 B 收到来自主机 A 的 MSS 值 16K。
  3. 主机 B 将其发送 MSS 值设置为 16K。
  4. 主机 B 将其 MSS 值 8K 发送到主机 A。
  5. 主机 A 收到来自主机 B 的 MSS 值 8K。
  6. 主机 A 将其发送 MSS 值设置为 8K。

为了帮助在 TCP 连接终端避免 IPv4 分段,MSS 值的选择被改为最小缓冲区大小和传出接口的 MTU (- 40 字节)。由于 MSS 只是 TCP 数据的大小,不包括 20 字节的 IPv4 报头和 20 字节的 TCP 报头,因此 MSS 值比 MTU 值要小 40 个字节。MSS 基于默认报头大小;发送端堆栈必须根据使用的 TCP 或 IPv4 选项减去 IPv4 报头和 TCP 报头的相应值。

MSS 现在的工作方式是,各个主机首先比较传出接口的 MTU 和自己的缓冲区大小,然后选择最小的值作为发送 MSS 值。主机然后比较收到的 MSS 大小和自己的接口 MTU,然后选择两者之间的较小值。

场景 2 说明了发送者为避免在本地和远程线路上分段而需要额外采取的步骤。请关注各个主机(在相互发送自己的 MSS 值之前)如何考虑传出接口的 MTU 以及这如何有助于避免分段。

场景 2

场景2
  1. 主机 A 比较其 MSS 缓冲区 (16K) 和其 MTU (1500 - 40 = 1460),并使用较小的值作为 MSS (1460),以便发送到主机 B。
  2. 主机 B 收到主机 A 的发送 MSS (1460),并将其与出站接口 MTU - 40 的值 (4422) 相比较。
  3. 主机 B 将较低的值 (1460) 设置为 MSS,以便向主机 A 发送 IPv4 数据报。
  4. 主机 B 比较其 MSS 缓冲区 (8K) 和其 MTU (4462 - 40 = 4422),并使用 4422 作为 MSS,以便发送到主机 A。
  5. 主机 A 收到主机 B 的发送 MSS (4422),并将其与出站接口 MTU - 40 的值 (1460) 相比较。
  6. 主机 A 将较低的值 (1460) 设置为 MSS,以便向主机 B 发送 IPv4 数据报。

1460 便是两台主机为彼此选择的发送 MSS 的值。通常 TCP 连接两端的发送 MSS 值相同。

在场景 2 中,由于主机考虑到各自的传出接口 MTU,因此 TCP 连接终端不会发生分段。如果路由器 A 与路由器 B 之间链路的 MTU 低于任一主机的出站接口 MTU,则在两个路由器之间的网络中仍会对数据包分段。

TCP和UDP的重要特性

OSI模型

总结

TCP

除了提供分段、提供端号之外,还提供其他的,所以可靠,但是对带宽消耗大

  • TCP: 传输控制协议–面向连接的可靠传输协议
  • 除完成传输层基本工作外,还需要保障数据的可靠传输;
  • 面向连接:三次握手–建立端到端的虚链路
  • 可靠传输:确认、重传、排序、流控(滑动窗口机制)

注:对于带宽的占用较高;不建议传输实时流量  仅支持单播

排序:每个包上都有相应的序号;

流控一般窗口号是几就发多个包一次性回确认,再加包1000变成2000回确认,如果只收了前1500后500没有收到则变成1500

(即降速——>升速——>降速——>升速——>… …)

TCP 协议中的 PSH 和 URG

TCP Flag 字段中有两个较为少用的标志:

  • PSH:推送

  • URG:紧急

PSH 标志

要明白 PSH 标志,得先了解 TCP 是如何缓冲数据的。如下图所示:

发送方从应用层接收数据到缓冲区直到达到某个大小开始发送;接收方从缓冲区接收数据,直到达到某个大小开始上报给用户层。在大多数情况下,这种工作模式是很有效率的。

试想在要求实时交互通信的场景(比如启动一个 Telnet 连接):一端的应用进程希望在键入一个命令后立即就能收到对方的响应。如果还是上述的工作模式,有可能你输入的数据太少,未满足发送缓冲大小导致无法发送亦或者接收到的数据太小还没有投递到应用层,这样都会导致响应的不及时。

引入 PSH 标志,可以做到:

  • 提醒发送方立即发送这段数据;

  • 提醒接收方立即将数据投递到应用层;

说白了,就是:赶快发,赶快收。

URG 标志

区别于 PSH 标志,URG 标志的使用必须结合 URG 指针,如下图所示:

要理解 URG 标志,得先了解什么是「紧急数据」。顾名思义,紧急数据就是优先级非常高,需要立即处理的数据。例如,一个程序在远程主机上运行并与之有大量的数据通讯,后发生一些问题,需要立刻取消该程序的运行,故从键盘中发出中断命令(Ctrl+G)。如果不使用紧急数据,则这两个字符将被存储在 TCP 发送数据的末尾发送,且接收方也在处理完其他数据后最后处理这两个字符,从而浪费很多时间。

当 URG = 1 时,发送应用进程就告诉发送方 TCP 有紧急数据要传送,于是发送方 TCP 就把紧急数据插入到报文段的最前面,而紧急数据后面的数据仍然是普通数据。紧急指针(Urgent Pointer)就是表示本报文段中紧急数据的字节数(紧急数据结束后就是普通数据),即紧急数据末尾在报文段中的位置。当所有紧急数据都处理完,TCP 就告诉应用层序恢复到正常操作。值得注意的是,即使窗口为 0,也可发紧急数据。

UDP

只提供分段和端号,不可靠,但是对带宽占用小

  • UDP:用户数据报文协议–非面向连接的不可靠传输协议

  • 仅完成传输的基本工作–分段、端口

  • 对于带宽的占用较低,常用于实时流量的传输

  • 支持单播、组播、广播    注: Window size: TCP窗口机制(主要是滑动窗口机制)中TCPheader中的字段;指接收端的窗口,即接收窗口,用来告知发送端自己所能接收的数据量,从而达到一部分流控的目的

  • MTU:最大传输单元,1500k

  • 端口号:0-65535

    • 1-1023注明端口
    • 1024-65535:高端口-动态端口
         目标服务              源端进程
  (可以同一个服务器提供不同的服务) (即分配给QQ等程序的,电脑中的进程号)

IPV4报头:

ARP:地址解析协议—通过对端的某个地址来获取对端的另一个地址
AARP:正向ARP —已知对端的IP地址,通过广播来获取对赌的MAC地址(在一个广播域内)
RARP:反向ARP — 已知对端MAC地址,通过二层单播来获取对端的IP(二层单播)
FARP:无故ARP ---- 刚使用IP地址时,对将要使用的IP地址,进行正向ARP;用于地址的冲突检测(即在手动配IP后做的地址冲突检测)

TCP/IP和OSI模型的区别:

  1. 层数不同 5层或4层;7层
  2. TCP/IP仅支持的IP协议;OSI支持所有的网络层
  3. TCP/IP协议支持的跨层封装 应用层直接封装到3层或2层;用于设备间沟通的流量

补充:

应用程序间沟通的流量正常不会跨层,跨层封装只有5层—>3层和5层—>2层
当4层被取消时,分段和进程标记的功能就没有了,此时3层报头将完成这一工作
使用分片行为,将流量分片后逐一填充到IPV4报头内,使用协议号来标示上层的信息
当3/4层都被取消时,2层报头将完成分段和进程标记的功能
以太网第二代封装技术,仅存在类型号可以标记进程, 但无分片功能 ,若需要跨层封装到二层时,将使用以太网第一代帧——IEEE802.2和802.3标准(即使用LLC和MAC两个子层构成)

TCP/UDP常用服务端口列表

端口 描述 状态
0/TCP,UDP 保留端口;不使用(若发送过程不准备接受回复消息,则可以作为源端口) 官方
1/TCP,UDP TCPMUX(传输控制协议端口服务多路开关选择器) 官方
5/TCP,UDP RJE(远程作业登录) 官方
7/TCP,UDP Echo(回显)协议 官方
9/UDP 抛弃协议 官方
9/TCP,UDP 网络唤醒 非官方
11/TCP,UDP SYSTAT协议 官方
13/TCP,UDP DAYTIME协议 官方
15/TCP,UDP NETSTAT协议 官方
17/TCP,UDP QOTD(Quote of the Day,每日引用)协议 官方
18/TCP,UDP 消息发送协议 官方
19/TCP,UDP CHARGEN(字符发生器)协议 官方
20/TCP,UDP 文件传输协议 - 默认数据端口 官方
21/TCP,UDP 文件传输协议 - 控制端口 官方
22/TCP,UDP SSH(Secure Shell) - 安全远程登录协议,用于安全文件传输(SCPSFTP)及端口转发 官方
23/TCP,UDP Telnet终端仿真协议 - 未加密文本通信 官方
25/TCP,UDP SMTP(简单邮件传输协议) - 用于传递电子邮件 官方
26/TCP,UDP RSFTP - 一个简单的类似FTP的协议 非官方
35/TCP,UDP 任意的私有打印机服务端口 非官方
37/TCP,UDP TIME时间协议 官方
39/TCP,UDP Resource Location Protocol(资源定位协议) 官方
41/TCP,UDP 图形 官方
42/TCP,UDP Host Name Server 官方
42/TCP,UDP WINS(WINS主机名服务) 非官方
43/TCP WHOIS协议 官方
49/TCP,UDP TACACS登录主机协议 官方
53/TCP,UDP DNS(域名服务系统) 官方
56/TCP,UDP 远程访问协议 官方
57/TCP MTP,邮件传输协议 官方
67/UDP BOOTP(BootStrap协议)服务;同时用于动态主机设置协议 官方
68/UDP BOOTP客户端;同时用于动态主机设定协议 官方
69/UDP 小型文件传输协议(小型文件传输协议) 官方
70/TCP Gopher 官方
79/TCP 手指协议 官方
80/TCP,UDP 超文本传输协议(超文本传输协议)或快速UDP网络连接- 用于传输网页 官方
81/TCP XB Browser - Tor 非官方
82/UDP XB Browser - 控制端口 非官方
88/TCP Kerberos - 认证代理 官方
101/TCP 主机名 官方
102/TCP ISO-TSAP协议 官方
107/TCP 远程Telnet协议 官方
109/TCP 邮局协议(POP),第2版 官方
110/TCP 邮局协议,第3版 - 用于接收电子邮件 官方
111/TCP,UDP Sun远程过程调用协议 官方
113/TCP Ident - 旧的服务器身份识别系统,仍然被IRC服务器用来认证它的用户 官方
115/TCP 简单文件传输协议 官方
117/TCP UNIX间复制协议Unix to Unix Copy Protocol,UUCP)的路径确定服务 官方
118/TCP,UDP SQL服务 官方
119/TCP 网络新闻传输协议 - 用来收取新闻组的消息 官方
123/UDP NTP(Network Time Protocol) - 用于时间同步 官方
135/TCP,UDP 分布式运算环境(Distributed Computing Environment,DCE)终端解决方案及定位服务 官方
135/TCP,UDP 微软终端映射器(End Point Mapper,EPMAP) 官方
137/TCP,UDP NetBIOS NetBIOS 名称服务 官方
138/TCP,UDP NetBIOS NetBIOS 数据报文服务 官方
139/TCP,UDP NetBIOS NetBIOS 会话服务 官方
143/TCP,UDP 因特网信息访问协议(IMAP) - 用于检索电子邮件 官方
152/TCP,UDP BFTP, 后台文件传输程序 官方
153/TCP,UDP 简单网关监控协议(Simple Gateway Monitoring Protocol,SGMP) 官方
156/TCP,UDP SQL服务 官方
158/TCP,UDP DMSP, 分布式邮件服务协议 非官方
161/TCP,UDP 简单网络管理协议(SNMP) 官方
162/TCP,UDP SNMP协议的TRAP操作 官方
170/TCP 打印服务 官方
179/TCP 边界网关协议 (BGP) 官方
194/TCP IRC(互联网中继聊天) 官方
201/TCP,UDP AppleTalk 路由维护 官方
209/TCP,UDP Quick Mail 传输协议 官方
213/TCP,UDP 互联网分组交换协议(IPX) 官方
218/TCP,UDP MPP,信息发布协议 官方
220/TCP,UDP 因特网信息访问协议(IMAP),第3版 官方
259/TCP,UDP ESRO, Efficient Short Remote Operations 官方
264/TCP,UDP BGMP,边界网关多播协议 官方
308/TCP Novastor 在线备份 官方
311/TCP Apple 服务器管理员工具、工作组管理 官方
318/TCP,UDP TSP,时间戳协议 官方
323/TCP,UDP IMMP, Internet消息映射协议 官方
383/TCP,UDP HP OpenView HTTPs 代理程序 官方
366/TCP,UDP ODMR,按需邮件传递 官方
369/TCP,UDP Rpc2 端口映射 官方
371/TCP,UDP ClearCase 负载平衡 官方
384/TCP,UDP 一个远程网络服务器系统 官方
387/TCP,UDP AURP,AppleTalk 升级用路由协议 官方
389/TCP,UDP 轻型目录访问协议 LDAP 官方
401/TCP,UDP 不间断电源(UPS) 官方
411/TCP Direct Connect Hub 端口 非官方
412/TCP Direct Connect 客户端—客户端 端口 非官方
427/TCP,UDP 服务定位协议(SLP) 官方
443/TCP 超文本传输安全协议QUIC 官方
444/TCP,UDP SNPP,简单网络分页协议 官方
445/TCP Microsoft-DS (Active Directory、Windows 共享、震荡波蠕虫、Agobot、Zobotworm) 官方
445/UDP Microsoft-DS 服务器消息块(SMB)文件共享 官方
464/TCP,UDP Kerberos 更改/设定密码 官方
465/TCP Cisco 专用协议 官方
465/TCP 传输层安全性协议加密的简单邮件传输协议 官方
475/TCP tcpnethaspsrv(Hasp 服务,TCP/IP 版本) 官方
497/TCP dantz 备份服务 官方
500/TCP,UDP 网络安全关系与密钥管理协议,IKE-Internet 密钥交换 官方
502/TCP,UDP Modbus 协议 官方
512/TCP exec,远程进程执行 官方
512/UDP comsat 和 biff 命令:用于电子邮件系统 官方
513/TCP login,登录命令 官方
513/UDP Who命令,查看当前登录计算机的用户 官方
514/TCP 远程外壳 protocol - 用于在远程计算机上执行非交互式命令,并查看返回结果 官方
514/UDP Syslog 协议 - 用于远程日志 官方
515/TCP Line Printer Daemon protocol - 用于 LPD 打印机服务器 官方
517/UDP Talk 官方
518/UDP NTalk 官方
520/TCP efs 官方
520/UDP Routing - 路由信息协议 官方
513/UDP 路由器 官方
524/TCP,UDP NetWare核心协议(NetWare 核心协议)用于一系列功能,例如访问NetWare主服务器资源、同步时间等 官方
525/UDP Timed,时间服务 官方
530/TCP,UDP 远程过程调用 官方
531/TCP,UDP AOL 即时通信软件, IRC 非官方
532/TCP netnews 官方
533/UDP netwall,用于紧急广播 官方
540/TCP UUCP(Unix-to-Unix 复制协议) 官方
542/TCP,UDP 商业(Commerce Applications) 官方
543/TCP klogin,Kerberos登陆 官方
544/TCP kshell,Kerberos 远程shell 官方
546/TCP,UDP DHCPv6客户端 官方
547/TCP,UDP DHCPv6服务器 官方
548/TCP 通过传输控制协议(TCP)的 Appletalk 文件编制协议(AFP(苹果归档协议)) 官方
550/UDP new-rwho,new-who 官方
554/TCP,UDP 即时流协议 官方
556/TCP Brunhoff 的远程文件系统(RFS) 官方
560/UDP rmonitor, Remote Monitor 官方
561/UDP monitor 官方
563/TCP,UDP 通过TLS网络新闻传输协议(NNTPS) 官方
587/TCP 邮件消息提交(简单邮件传输协议RFC 2476 官方
591/TCP FileMaker 6.0(及之后版本)网络共享(HTTP的替代,见80端口) 官方
593/TCP,UDP HTTP RPC Ep Map(RPC over HTTP, often used by Distributed COM services and Microsoft Exchange Server 官方
604/TCP TUNNEL 官方
631/TCP,UDP 互联网打印协议
636/TCP,UDP LDAP over TLS(加密传输,也被称为LDAPS) 官方
639/TCP,UDP MSDP,组播源发现协议 官方
646/TCP,UDP LDP,标签分发协议 官方
647/TCP DHCP故障转移协议 官方
648/TCP RRP(Registry Registrar Protocol),注册表注册协议 官方
652/TCP DTCP(Dynamic Tunnel Configuration Protocol),动态主机设置协议 官方
654/UDP AODV(Ad hoc On-Demand Distance Vector),无线自组网按需平面距离向量路由协议 官方
665/TCP sun-dr, Remote Dynamic Reconfiguration 非官方
666/UDP 毁灭战士,电脑平台上的一系列第一人称射击游戏 官方
674/TCP ACAP(Application Configuration Access Protocol),应用配置访问协议 官方
691/TCP MS Exchange Routing 官方
692/TCP Hyperwave-ISP
694/UDP 用于带有高可用性的聚类的心跳服务 非官方
695/TCP IEEE-MMS-SSL
698/UDP OLSR(Optimized Link State Routing),优化链路状态路由协议
699/TCP Access Network
700/TCP EPP, 可扩展供应协议
701/TCP LMP,链路管理协议
702/TCP IRIS over BEEP
706/TCP SILC,Secure Internet Live Conferencing
711/TCP TDP,标签分发协议
712/TCP TBRPF,Topology Broadcast based on Reverse-Path Forwarding
720/TCP SMQP,Simple Message Queue Protocol
749/TCP,UDP kerberos-adm,Kerberos administration
750/UDP Kerberos version IV
782/TCP Conserver serial-console management server
829/TCP 证书管理协议(CMP)[2]
860/TCP ISCSI,Internet小型计算机系统接口
873/TCP Rsync,文件同步协议 官方
901/TCP Samba 网络管理工具(SWAT) 非官方
902 VMware服务器控制台[3] 非官方
904 VMware服务器替代(如果902端口已被占用) 非官方
911/TCP Network Console on Acid(NCA) - local tty redirection over OpenSSH
981/TCP Check Point Remote HTTPS management for firewall devices running embedded Checkpoint Firewall-1 software 非官方
989/TCP,UDP FTP Protocol (data) over TLS/SSL 官方
990/TCP,UDP FTP Protocol (control) over TLS/SSL 官方
991/TCP,UDP NAS (Netnews Admin System)
992/TCP,UDP 基于TLS/SSL的Telnet协议 官方
993/TCP 基于 传输层安全性协议因特网信息访问协议 (加密传输) 官方
995/TCP 基于 传输层安全性协议邮局协议 (加密传输) 官方

本文不允许转载。
  目录