Tcp之异常

Tcp异常

昨研发报异常,据CMCC说是我方服务器主动断开的,于是怀疑是超时设置过短,于是我抓包,由于我接触socket时日尚短,搞不清为什么三次握手成功之后我方服务器会立刻发送fin

今天本来做实验观察进程IP复用情况,却无意中揭开了此问题的面纱,特此记录

我们首先来说说,ip复用的情况,具体ip能被复用多少次,记得从哪本书上模糊看到关于此的文章,不记得了。废话不多说,上源码先

#!/usr/local/bin/python3.5

#coding:utf-8

import socket

port = 8080

host = ‘192.168.1.210‘

while True:

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

s.connect((host, port))

此源码相信很多人都能看懂,就干一件事,疯狂的建立三次握手。运行大概十几秒之后,程序抛出异常

异常说我无法请求分配的地址,我看字面意思还以为是IP复用资源用尽了,结果原来是因为

socket发起connect请求的时候会随机分配一个端口给你。这个分配的端口是有范围的,记录在:

共计可用端口为28232

再写一个小脚本监控下连接数,发现

刨去22和mysql这两个持久链接,刚好等于28232

好了,这个问题解决了,那我们看看顺手而来的收获吧

情况何其像似由此我们也知道了,在程序没有可发送的数据后,会自动发送一个FIN,代表我已无数据发送了,即使程序没发送任何数据,在刚链接建立就FIN也是可以的(当然通常咱们不这样搞,TCP毕竟是比较奢侈的协议)所以这不是由于服务器设置的的time时间造成的。

至于在这个过程中,各种状态的转换,又是另外一个故事了…

END!

时间: 2024-12-19 05:47:15

Tcp之异常的相关文章

(转)TCP连接异常断开检测

TCP是一种面向连接的协议,连接的建立和断开需要通过收发相应的分节来实现.某些时候,由于网络的故障或是一方主机的突然崩溃而另一方无法检测到,以致始终保持着不存在的连接.下面介绍一种方法来检测这种异常断开的情况 TAG: TCP连接异常断开  TCP断链 TCP是一种面向连接的协议,连接的建立和断开需要通过收发相应的分节来实现.某些时候,由于网络的故障或是一方主机的突然崩溃而另一方无法检测到,以致始终保持着不存在的连接.下面介绍一种方法来检测这种异常断开的情况 1) 在TCP协议中提供了KEEPA

关于心跳ajax请求pending状态(被挂起),stalled时间过长的问题。涉及tcp连接异常。

环境:景安快云服务器(听说很垃圾,但是公司买的,我也刚来),CentOS-6.8-x86_64,Apache,MySQL5.1,PHP5.3. 问题:现公司有一个php系统,需要重复向后台发送ajax请求,但是会出现pending状态,我现在需要解决这个问题,或者说找到问题在服务器,代码,还是客户端,然后有个交代,但是不知道从何下手,毕竟还是it萌新啊.. 效果如图.两个特点,1:就是越往后的请求,pengding时间越长,且其中绝大部分时间被stalled占用(此问题网上有相关文章,但是没有解

TCP中异常关闭链接的意义 异常关闭的情况

终止一个连接的正常方式是发送FIN. 在发送缓冲区中 所有排队数据都已发送之后才发送FIN,正常情况下没有任何数据丢失. 但我们有时也有可能发送一个RST报文段而不是F IN来中途关闭一个连接.这称为异常关闭 . 进程关闭socket的默认方式是正常关闭,如果需要异常关闭,利用 SO_LINGER选项来控制. 异常关闭一个连接对应用程序来说有两个优点: (1)丢弃任何待发的已经无意义的 数据,并立即发送RST报文段: (2)RST的接收方利用关闭方式来 区分另一端执行的是异常关闭还是正常关闭.

TCP异常连接的检测方法

背景 在平时的开发中,经常会碰到一些需要检测tcp连接是否正常的场景.比如一个分布式的应用,一个调度任务的节点管理一堆用来跑业务的节点.当调度节点进行调度的时候,需要把任务分发给它认为正常的业务节点去执行.业务节点是否正常,一个重要的参考依据就是调度节点和业务节点之间的tcp连接是否正常.这时候就需要调度节点主动地去检测tcp连接.常见的检测方法有以下几种 方案一.通过TCP协议的返回值进行判断 <1> 利用select,把socket设置为非阻塞.然后使用select等待该socket的可读

再次对比TCP与UDP

免责声明:和往常一样,此文章的观点都属于'No Bugs'Hare(译注:一个网站) ,也许不一定和翻译者或者Overload编辑的意见一致.同时,翻译者从Lapine翻译到英语也具有一定的难度.除此之外,翻译者与Overload对于从阅读此文章所带来的后果或不作为明确不负任何责任. 原文地址:Once Again on TCP vs UDP 讨论TCP与UDP的好与坏几乎与Linux和windows的争辩有着一样长的历史.我一直支持一个观点,也就是:UDP与TCP都有各自的适用场景(比如:[N

[转帖]脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手

脑残式网络编程入门(一):跟着动画来学TCP三次握手和四次挥手 http://www.52im.net/thread-1729-1-1.html 1.引言 网络编程中TCP协议的三次握手和四次挥手的问题,在面试中是最为常见的知识点之一.很多读者都知道"三次"和"四次",但是如果问深入一点,他们往往都无法作出准确回答. 本篇文章尝试使用动画图片的方式,来对这个知识点进行"脑残式"讲解(哈哈),期望读者们可以更加简单.直观地理解TCP网络通信交互的本

Bugzilla系统使用规范

一 Bugzilla的状态 状态                                              说明 unconfirmed 未确定(针对反馈Bug/需求) confirming 确认中(针对反馈需求) new 新建 assigned 已分配 resolved 已解决 verified 已验证 closed 已关闭 reopened 重新打开 二 Bugzilla的解决途径 解决途径                                         说明

比isConnected()更靠谱的的获取socket实时连接状态!

看到这个标题,预计非常多人会说用socket.isConnected()或者socket.isClosed()等方法来推断即可了,但其实这些方法都是訪问socket在内存驻留的状态,当socket和server端建立链接后,即使socket链接断掉了,调用上面的方法返回的仍然是链接时的状态,而不是socket的实时链接状态.以下给出样例证明这一点. server端: package com.csc.server; import java.net.*; /** * @description 从这里

心跳包

转自:http://blog.csdn.net/gao5528/article/details/6029160 心跳包就是在客户端和服务器间定时通知对方自己状态的一个自己定义的命令字,按照一定的时间间隔发送,类似于心跳,所以叫做心跳包. 用来判断对方(设备,进程或其它网元)是否正常运行,采用定时发送简单的通讯包,如果在指定时间段内未收到对方响应,则判断对方已经离线.用于检测TCP的异常断开.基本原因是服务器端不能有效的判断客户端是否在线,也就是说,服务器无法区分客户端是长时间在空闲,还是已经掉线