如何测试一个服务器的某一端口是否开通?如本机127.0.0.1下的5000端口!谢谢各位大侠

时间:2022-06-01 22:09:12
如何测试一个服务器的某一端口是否开通?如本机127.0.0.1下的5000端口!谢谢各位大侠

10 个解决方案

#1


TCP吗?执行“telnet 127.0.0.1 5000”

#2


是啊,如何在VC中实现啊?请教

#3


看来这位兄弟的网络课程没有学好,是不是在上课的时候只记者偷看前面的美女了?TCP有一个三次握手,就是利用这个可以探测是否打开了端口,具体的实现自己去查一下,这样的源代码很多的,端口扫描程序也是很多。

#4


bind端口不成功,已经被占用

connect端口成功,该端口正在listen

#5


connect

#6


tcp用 connect
udp可向该端口发一任意数据,若是开着的(即正在recvfrom),则无ICMP消息返回,若收到ICMP消息,则没有打开。

这不是教你端口扫描吗~~~~~~~~~~

#7


TCP安全一点的话,可以用半打开扫描

#8


UDP那样做不能保证100%成功。因为它的传输不可靠

#9


UDP的connect函数
    除非套接口已连接,否则异步错误是不会返回到UDP套接口的。实际上,我们可以给UDP套接口调用connect,但这样做的结果却与TCP连接毫不相同,没有三路握手过程。内核只是记录对方的IP地址和端口号,它们包含在传递给connect的套接口地址结梅中,并立即返回给调用进程。
    给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定:sockname是本地协议地址,而peername是远程协议地址,则更好的名字可能是setpeername。类似地,函数bind的更好名字也许是setsockname。
    有了这个能力后,我们必须区分;
    ·未连接UDP套接口(unconnected UDP socket),当我们创建UDP套接口时,缺省为此;
    ·已连接UDP套接口(connected UDP socket),对UDP套接口调用connect的结果。
    对于已连接UDP套接口,与缺省的未连接UDP套接口相比,发生了三个变化:
    1.我们再也不能给输出操作指定目的IP地址和端口号。也就是说,我们不使用sendto,而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
    与TCP相似,我们可以给已连接UDP套接口调用sendto,但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针,第六个参数(套接口地址结构的大小)应为0。Posix.1g规定,当第五个参数是空指针时,就不再考虑第六个参数的取值情况。
    2.我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号),但不是从connect所指定套接口协议地址到达的数据报,不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说,一个已连接UDP套接口仅与一个IP地址交换数据报,因为connect到多播或广播地址是可能的。
    3.异步错误由已连接UDP套接口返回给进程,由此推断,未连接UDP套接口不接收任何异步错误,这在前面我们已描述过。
图8.14就4.4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│                  │              │不指定目的    │                    │
│套接口类型        │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口        │  可以        │可以          │    EISCONN         │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口,已连接│  可以        │可以          │    EISCONN         │
│UDP 套接口,未连接│EDESTADDRREQ  │EDESTADDRREQ  │    可以            │
└─────────┴───────┴───────┴──────────┘
           图8.14 TCP和UDP套接口:可指定目的协议地址吗?
    POSIX.1g指出,在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN,而不是EDESTADDRREQ。
    Solaris 2.5允许sendto给已连接UDP套接口指定目的地址,而Posix.lg规定应返回EISCONN。
    图8.15就我们给已连接UDP套接口所归纳的三点做了一个小结。
                    ┌─────┐                        ┌─────┐
                    │ 应用进程 │                        │ 对方进程 │
                    └──┬┬─┘                        └──┬┬─┘
                      read↑↓write                             ↑↓
                    ┌──┴┴─┐从connect存储对方      ┌──┴┴─┐
             ???←─┤UDP ││  │的IP地址和端口号       │UDP ││  │
                    └┬─┬┬─┘                        └──┬┬─┘
                      ↑  ↑↓          UDP 数据报              ↑│
──────────→┘  │└────────────────→┘↓
来自于其他IP地址和/或    └←──────────────────┘
端口号的UDP数据报                      UDP数据报
                图8.15已连接UDP套接口
    应用进程调用connect,指定对方的IP地址和端口号,然后用read和write来与对方交换数据。
    从任何其他IP地址或端口(图8.15中我们用“???”表示)到达的数据报不递送给已连接套接口,因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口,UDP将丢弃它并生成一个ICMP端口不可达错误。
    作为小结,仅在进程用UDP套接口与确定的唯一对方进行通信时,UDP客户或服务器才可以调用connect。一般来说,都是UDP客户调用connect,但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP),这种情况下,客户和服务器都可调用connect。
    DNS提供了另一个例子,如图8.16所示。
┌────┐        ┌────┐        ┌────┐        ┌────┐
│  DNS   ├───→│  DNS   ├───→│  DNS   ├───→│  DNS   │
│  客户  │←───┤ 服务器 │←───┤  客户  │←───┤ 服务器 │
└────┘        └────┘        └────┘        └────┘
connect成功         不能connect        不能connect         不能connect
(被配置成只使                           (被配置成使用
 用一个服务器)                           两个服务器)
              图8.16 DNS客户、服务器与函数connect的例子
    通过在文件/etc/resolv.conf中列出服务器的IP地址,DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框),客户可以调用connect,但如果列出多个服务器(图中从右边数第二个方框),客户就不能调用connect。而且,DNS服务器通常是处理任何客户的请求,所以服务器不能调用connect。

#10


这个是《UNIX网络编程——套接口API和X/0pen传输接口API》的“第8章 基本UDP套接口编程”,关于UDP编程讲的非常详细,建议大家找一本这样的书好好学习,会有很多收获的。平时编程经常出现的误区可以得以解决。其它方面的内容也很有帮助的。

#1


TCP吗?执行“telnet 127.0.0.1 5000”

#2


是啊,如何在VC中实现啊?请教

#3


看来这位兄弟的网络课程没有学好,是不是在上课的时候只记者偷看前面的美女了?TCP有一个三次握手,就是利用这个可以探测是否打开了端口,具体的实现自己去查一下,这样的源代码很多的,端口扫描程序也是很多。

#4


bind端口不成功,已经被占用

connect端口成功,该端口正在listen

#5


connect

#6


tcp用 connect
udp可向该端口发一任意数据,若是开着的(即正在recvfrom),则无ICMP消息返回,若收到ICMP消息,则没有打开。

这不是教你端口扫描吗~~~~~~~~~~

#7


TCP安全一点的话,可以用半打开扫描

#8


UDP那样做不能保证100%成功。因为它的传输不可靠

#9


UDP的connect函数
    除非套接口已连接,否则异步错误是不会返回到UDP套接口的。实际上,我们可以给UDP套接口调用connect,但这样做的结果却与TCP连接毫不相同,没有三路握手过程。内核只是记录对方的IP地址和端口号,它们包含在传递给connect的套接口地址结梅中,并立即返回给调用进程。
    给connect函数重载(overload)UDP套接口的这种能力容易让人混淆。如果使用约定:sockname是本地协议地址,而peername是远程协议地址,则更好的名字可能是setpeername。类似地,函数bind的更好名字也许是setsockname。
    有了这个能力后,我们必须区分;
    ·未连接UDP套接口(unconnected UDP socket),当我们创建UDP套接口时,缺省为此;
    ·已连接UDP套接口(connected UDP socket),对UDP套接口调用connect的结果。
    对于已连接UDP套接口,与缺省的未连接UDP套接口相比,发生了三个变化:
    1.我们再也不能给输出操作指定目的IP地址和端口号。也就是说,我们不使用sendto,而使用write或send。写到已连接UDP套接口上的任何东西都自动发送到由connect所指定的协议地址(例如IP地址和端口号)。
    与TCP相似,我们可以给已连接UDP套接口调用sendto,但不能指定目的地址。sendto的第五个参数(指向套接口地址结构的指针)必须为空指针,第六个参数(套接口地址结构的大小)应为0。Posix.1g规定,当第五个参数是空指针时,就不再考虑第六个参数的取值情况。
    2.我们不用recvfrom而用read或recv。在已连接UDP套接口上由内核为输入操作返回的唯一数据报是那些来自connect所指定协议地址的数据报。目的地址为已连接UDP套接口的本地协议地址(例如IP地址和端口号),但不是从connect所指定套接口协议地址到达的数据报,不传递给已连接套接口。这就限制了已连接UDP套接口能且只能与一个对方交换数据报。严格地说,一个已连接UDP套接口仅与一个IP地址交换数据报,因为connect到多播或广播地址是可能的。
    3.异步错误由已连接UDP套接口返回给进程,由此推断,未连接UDP套接口不接收任何异步错误,这在前面我们已描述过。
图8.14就4.4BSD总结了上面列表中第一点。
┌─────────┬───────┬───────┬──────────┐
│                  │              │不指定目的    │                    │
│套接口类型        │write 或 send │地址的 sendto │指定目的地址 sendto │
├─────────┼───────┼───────┼──────────┤
│TCP 套接口        │  可以        │可以          │    EISCONN         │
├─────────┼───────┼───────┼──────────┤
│UDP 套接口,已连接│  可以        │可以          │    EISCONN         │
│UDP 套接口,未连接│EDESTADDRREQ  │EDESTADDRREQ  │    可以            │
└─────────┴───────┴───────┴──────────┘
           图8.14 TCP和UDP套接口:可指定目的协议地址吗?
    POSIX.1g指出,在未连接UDP套接口上不指定目的地址的输出操作应返回ENOTCONN,而不是EDESTADDRREQ。
    Solaris 2.5允许sendto给已连接UDP套接口指定目的地址,而Posix.lg规定应返回EISCONN。
    图8.15就我们给已连接UDP套接口所归纳的三点做了一个小结。
                    ┌─────┐                        ┌─────┐
                    │ 应用进程 │                        │ 对方进程 │
                    └──┬┬─┘                        └──┬┬─┘
                      read↑↓write                             ↑↓
                    ┌──┴┴─┐从connect存储对方      ┌──┴┴─┐
             ???←─┤UDP ││  │的IP地址和端口号       │UDP ││  │
                    └┬─┬┬─┘                        └──┬┬─┘
                      ↑  ↑↓          UDP 数据报              ↑│
──────────→┘  │└────────────────→┘↓
来自于其他IP地址和/或    └←──────────────────┘
端口号的UDP数据报                      UDP数据报
                图8.15已连接UDP套接口
    应用进程调用connect,指定对方的IP地址和端口号,然后用read和write来与对方交换数据。
    从任何其他IP地址或端口(图8.15中我们用“???”表示)到达的数据报不递送给已连接套接口,因为要么源IP地址要么源UDP端口不与所连接的套接口协议地址相匹配。这些数据报可能递送给同一主机上的其他UDP套接口。如果到达的数据报没有其他匹配的套接口,UDP将丢弃它并生成一个ICMP端口不可达错误。
    作为小结,仅在进程用UDP套接口与确定的唯一对方进行通信时,UDP客户或服务器才可以调用connect。一般来说,都是UDP客户调用connect,但也有UDP服务器与单个客户长时间通信的应用程序(如TFTP),这种情况下,客户和服务器都可调用connect。
    DNS提供了另一个例子,如图8.16所示。
┌────┐        ┌────┐        ┌────┐        ┌────┐
│  DNS   ├───→│  DNS   ├───→│  DNS   ├───→│  DNS   │
│  客户  │←───┤ 服务器 │←───┤  客户  │←───┤ 服务器 │
└────┘        └────┘        └────┘        └────┘
connect成功         不能connect        不能connect         不能connect
(被配置成只使                           (被配置成使用
 用一个服务器)                           两个服务器)
              图8.16 DNS客户、服务器与函数connect的例子
    通过在文件/etc/resolv.conf中列出服务器的IP地址,DNS客户可被配置为使用一个或多个服务器。如果列出单个服务器(图中最左边的方框),客户可以调用connect,但如果列出多个服务器(图中从右边数第二个方框),客户就不能调用connect。而且,DNS服务器通常是处理任何客户的请求,所以服务器不能调用connect。

#10


这个是《UNIX网络编程——套接口API和X/0pen传输接口API》的“第8章 基本UDP套接口编程”,关于UDP编程讲的非常详细,建议大家找一本这样的书好好学习,会有很多收获的。平时编程经常出现的误区可以得以解决。其它方面的内容也很有帮助的。