社区
Linux/Unix社区
帖子详情
如何解决can't identify protocol的问题
search_you
2011-07-15 10:05:11
我写了一个EPOLL服务器,当客户端断开连接时已经关闭掉相应fd,用netstat -an查看已经没有连接,但是用lsof查看时会出现大量的can't identify protocol连接。不知道什么原因,如何解决?
...全文
1088
5
打赏
收藏
如何解决can't identify protocol的问题
我写了一个EPOLL服务器,当客户端断开连接时已经关闭掉相应fd,用netstat -an查看已经没有连接,但是用lsof查看时会出现大量的can't identify protocol连接。不知道什么原因,如何解决?
复制链接
扫一扫
分享
转发到动态
举报
写回复
配置赞助广告
用AI写文章
5 条
回复
切换为时间正序
请发表友善的回复…
发表回复
打赏红包
lvyinghong
2011-07-21
打赏
举报
回复
[Quote=引用 4 楼 search_you 的回复:]
引用 3 楼 lvyinghong 的回复:
这个好像是,主动断开的tcp端,有个time-wait状态,需要等一段时间比如两分钟才能完全释放fd吧。
不知道是不是这个原因,如果是自己写测试程序,在同一个机器上搞很多连接可能会碰到这个问题
这个有办法解决吗?
[/Quote]
你搜索一下 tcp TIME_WAIT 就知道了,这个应该是没办法避免的,只能不要开那么多的在同一个机器上。人家实际应用都是分布在不同客户机机器上的。如果你的服务器端主动断开,TIME_WAIT 全部都在一台机器上,只能说把 TIME_WAIT 时间改小一点了。尽量避免服务器端的 TIME_WAIT吧
search_you
2011-07-19
打赏
举报
回复
[Quote=引用 3 楼 lvyinghong 的回复:]
这个好像是,主动断开的tcp端,有个time-wait状态,需要等一段时间比如两分钟才能完全释放fd吧。
不知道是不是这个原因,如果是自己写测试程序,在同一个机器上搞很多连接可能会碰到这个问题
[/Quote]
这个有办法解决吗?
lvyinghong
2011-07-15
打赏
举报
回复
这个好像是,主动断开的tcp端,有个time-wait状态,需要等一段时间比如两分钟才能完全释放fd吧。
不知道是不是这个原因,如果是自己写测试程序,在同一个机器上搞很多连接可能会碰到这个问题
search_you
2011-07-15
打赏
举报
回复
不管的话会耗尽文件描述符啊,之后会出现too many open files的错误,我已经把系统能打开的最大文件数设置为65535了。abao623660072,你的头像太性感了,呵呵!
金刚葫芦娃
2011-07-15
打赏
举报
回复
不需要管.
TCP IP Illustrated, Vol 1 The
Pro
tocol
s 2nd.pdf
Introduction This book describes the TCP/IP
pro
tocol
suite, but from a different perspective than other texts on TCP/IP. Instead of just describing the
pro
tocol
s and what they do, we'll use a popular diagnostic tool to watch the
pro
tocol
s in action. Seeing how the
pro
tocol
s operate in varying circumstances
pro
v
ide
s a greater understanding of how they work and why certain design decisions were made. It also
pro
v
ide
s a look into the implementation of the
pro
tocol
s, without having to wade through thousands of lines of source code. When networking
pro
tocol
s were being developed in the 1960s through the 1980s, expensive, dedicated hardware was required to see the packets going "across the wire." Extreme familiarity with the
pro
tocol
s was also required to comprehend the packets displayed by the hardware. Functionality of the hardware analyzers was limited to that built in by the hardware designers. Today this has changed dramatically with the ability of the ubiquitous workstation to monitor a local area network Mogul 1990. Just attach a workstation to your network, run some publicly available software (described in Appendix A), and watch what goes by on the wire. While many people cons
ide
r this a tool to be used for diagnosing network
pro
blems, it is also a powerful tool for understanding how the network
pro
tocol
s operate, which is the goal of this book. This book is intended for anyone wishing to understand how the TCP/IP
pro
tocol
s operate:
pro
grammers writing network applications, system administrators responsible for maintaining computer systems and networks utilizing TCP/IP, and users who deal with TCP/IP applications on a daily basis. Organization of the Book We take a bottom-up ap
pro
ach to the TCP/IP
pro
tocol
suite. After
pro
viding a basic introduction to TCP/IP in Chapter 1, we will start at the link layer in Chapter 2 and work our way up the
pro
tocol
stack. This
pro
v
ide
s the required background for later chapters for readers who aren't familiar with TCP/IP or networking in general. This book also uses a functional ap
pro
ach instead of following a strict bottom-to-top order. For example, Chapter 3 describes the IP layer and the IP header. But there are numerous fields in the IP header that are best described in the context of an application that uses or is affected by a particular field. Fragmentation, for example, is best understood in terms of UDP (Chapter 11), the
pro
tocol
often affected by it. The time-to-live field is fully described when we look at the Traceroute
pro
gram in Chapter 8, because this field is the basis for the operation of the
pro
gram. Similarly, many features of ICMP are described in the later chapters, in terms of how a particular ICMP message is used by a
pro
tocol
or an application. We also don't want to save all the good stuff until the end, so we describe TCP/IP applications as soon as we have the foundation to understand them. Ping and Traceroute are described after IP and ICMP have been discussed. The applications built on UDP (multicasting, the DNS, TFTP, and BOOTP) are described after UDP has been examined. The TCP applications, however, along with network management, must be saved until the end, after we've thoroughly described TCP. This text focuses on how these applications use the TCP/IP
pro
tocol
s. We do not
pro
v
ide
all the details on running these applications. Readers This book is self-contained and assumes no specific knowledge of networking or TCP/IP. Numerous references are
pro
v
ide
d for readers interested in additional details on specific topics. This book can be used in many ways. It can be used as a self-study reference and covered from start to finish by someone interested in all the details on the TCP/IP
pro
tocol
suite. Readers with some TCP/IP background might want to skip ahead and start with Chapter 7, and then focus on the specific chapters in which they're interested. Exercises are
pro
v
ide
d at the end of the chapters, and most solutions are in Appendix D. This is to maximize the usefulness of the text as a self-study reference. When used as part of a one- or two-semester course in computer networking, the focus should be on IP (Chapters 3 and 9), UDP (Chapter 11), and TCP (Chapters 17-24), along with some of the application chapters. Many forward and backward references are
pro
v
ide
d throughout the text, along with a thorough index, to allow individual chapters to be studied by themselves. A list of all the acronyms used throughout the text, along with the compound term for the acronym, appears on the ins
ide
back covers. If you have access to a network you are encouraged to obtain the software used in this book (Appendix F) and experiment on your own. Hands-on experimentation with the
pro
tocol
s will
pro
v
ide
the greatest knowledge (and make it more fun). Systems Used for Testing Every example in the book was run on an actual network and the resulting output saved in a file for inclusion in the text. Figure 1.11 (p. 18) shows a diagram of the different hosts, routers, and networks that are used. (This figure is also duplicated on the ins
ide
front cover for easy reference while reading the book.) This collection of networks is simple enough that the topology doesn't confuse the examples, and with four systems acting as routers, we can see the error messages generated by routers. Most of the systems have a name that indicates the type of software being used: bsdi, svr4, sun, solaris, aix, slip, and so on. In this way we can
ide
ntify
the type of software that we're dealing with by looking at the system name in the printed output. A w
ide
range of different operating systems and TCP/IP implementations are used: BSD/386 Version 1.0 from Berkeley Software Design, Inc., on the hosts named bsdi and slip. This system is derived from the BSD Networking Software, Release 2.0. (We show the lineage of the various BSD releases in Figure 1.10 on p. 17.) Unix System V/386 Release 4.0 Version 2.0 from U.H. Corporation, on the host named svr4. This is vanilla SVR4 and contains the standard implementation of TCP/IP from Lachman Associates used with most versions of SVR4. SunOS 4.1.3 from Sun Microsystems, on the host named sun. The SunOS 4.1.x systems are
pro
bably the most w
ide
ly used TCP/IP implementations. The TCP/IP code is derived from 4.2BSD and 4.3BSD. Solaris 2.2 from Sun Microsystems, on the host named solaris. The Solaris 2.x systems have a different implementation of TCP/IP from the earlier SunOS 4.1.x systems, and from SVR4. (This operating system is really SunOS 5.2, but is commonly called Solaris 2.2.) AIX 3.2.2 from IBM on the host named aix. The TCP/IP implementation is based on the 4.3BSD Reno release. 4.4BSD from the Computer Systems Research Group at the University of California at Berkeley, on the host vangogh.cs.berkeley.edu. This system has the latest release of TCP/IP from Berkeley. (This system isn't shown in the figure on the ins
ide
front cover, but is reachable across the Internet.) Although these are all Unix systems, TCP/IP is operating system independent, and is available on almost every popular non-Unix system. Most of this text also applies to these non-Unix implementations, although some
pro
grams (such as Traceroute) may not be
pro
v
ide
d on all systems. Typographical Conventions When we display interactive input and output we'll show our typed input in a bold font, and the computer output like this. Comments are added in italics. Also, we always include the name of the system as part of the shell
pro
mpt (bsdi in this example) to show on which host the command was run. Throughout the text we'll use indented, parenthetical notes such as this to describe historical points or implementation details. We sometimes refer to the complete description of a command in the Unix manual as in ifconfig(8). This notation, the name of the command followed by a number in parentheses, is the normal way of referring to Unix commands. The number in parentheses is the section number in the Unix manual of the "manual page" for the command, where additional information can be located. Unfortunately not all Unix systems organize their manuals the same, with regard to the section numbers used for various groupings of commands. We'll use the BSD-style section numbers (which is the same for BSD-derived systems such as SunOS 4.1.3), but your manuals may be organized differently. Acknowledgments Although the author's name is the only one to appear on the cover, the combined effort of many people is required to
pro
duce a quality text book. First and foremost is the author's family, who put up with the long and weird hours that go into writing a book. Thank you once again, Sally, Bill, Ellen, and David. The consulting editor, Brian Kernighan, is undoubtedly the best in the busin...
can't
ide
ntify
pro
tocol
问题
的定位和
解决
在观摩了一个关于性能
问题
排查的PPT之后试着用lsof命令来列举linux系统打开的文件, 然后发现出现了很多“ can't
ide
ntify
pro
tocol
” 的信息: udevd 3117 root 989u sock 0,4 84579 can't
ide
ntify
pro
tocol
udevd ...
关于 "can't
ide
ntify
pro
tocol
"
问题
的定位
转载地址:http://blog.csdn.net/tspangle/article/details/20543329 转载地址:http://blog.sina.com.cn/s/blog_62ec29160101qus8.html 感谢两位作者!
问题
定位步骤: 1、 用root帐户 遍历 /
pro
c/进程ID/fd目录,如果该目录下文件数比较
lsof: can't
ide
ntify
pro
tocol
问题
socket 泄露
lsof can't
ide
ntify
pro
tocol
句柄泄漏分析
前几天服务器上出现程序cpu标高,通过gdb看堆栈信息,发现Too many open files
问题
通过lsof -p pid |wc -l看到文件非常高 分析如下: 程序主要是通过360开源的evpp 调用libevent 的http接口实现简单http服务器功能。所以一开始就就直接怀疑是evpp开源代码出现的
问题
,然后就看源代码分析。看句柄释放位置,但是不得而终。 后面开...
Linux/Unix社区
23,117
社区成员
74,506
社区内容
发帖
与我相关
我的任务
Linux/Unix社区
Linux/Unix社区 应用程序开发区
复制链接
扫一扫
分享
社区描述
Linux/Unix社区 应用程序开发区
社区管理员
加入社区
获取链接或二维码
近7日
近30日
至今
加载中
查看更多榜单
社区公告
暂无公告
试试用AI创作助手写篇文章吧
+ 用AI写文章