socket是什么意思

SOCKET用于在两个基于TCP/IP协议的应用程序之间相互通信。最早出现在UNIX系统中，是UNIX系统主要的信息传递方式。在WINDOWS系统中，SOCKET称为WINSOCK。

两个基本概念：客户方和服务方。当两个应用之间需要采用SOCKET通信时，首先需要在两个应用之间（可能位于同一台机器，也可能位于不同的机器）建立SOCKET连接，发起呼叫连接请求的一方为客户方，接受呼叫连接请求的一方成为服务方。客户方和服务方是相对的，同一个应用可以是客户方，也可以是服务方。

在客户方呼叫连接请求之前，它必须知道服务方在哪里。所以需要知道服务方所在机器的IP地址或机器名称，如果客户方和服务方事前有一个约定就好了，这个约定就是PORT（端口号）。也就是说，客户方可以通过服务方所在机器的IP地址或机器名称和端口号唯一的确定方式来呼叫服务方。在客户方呼叫之前，服务方必须处于侦听状态，侦听是否有客户要求建立连接。一旦接到连接请求，服务方可以根据情况建立或拒绝连接。连接方式有两种，同步方式（Blocking）和(noBlocking).

客户方发送的消息可以是文本，也可以是二进制信息流。当客户方的消息到达服务方端口时，会自动触发一个事件（event），服务方只要接管该事件，就可以接受来自客户方的消息了。

socket 服务端是什么意思

网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个socket。

建立网络通信连接至少要一对端口号(socket)。socket本质是编程接口(API)，对TCP/IP的封装，TCP/IP也要提供可供程序员做网络开发所用的接口，这就是Socket编程接口；HTTP是轿车，提供了封装或者显示数据的具体形式;Socket是发动机，提供了网络通信的能力。

Socket的英文原义是“孔”或“插座”。作为BSD UNIX的进程通信机制，取后一种意思。通常也称作"套接字"，用于描述IP地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket正如其英文原意那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供220伏交流电， 有的提供110伏交流电，有的则提供有线电视节目。 客户软件将插头插到不同编号的插座，就可以得到不同的服务。

Socket跟HTTP协议两者有什么关系？利用HTTP协议通信跟socket通信有什么区别？

没错！

打个比喻：将socket比喻为高速公路，HTTP就是公路上跑的车。路上除了HTTP外，还有很多种其他类型的车，Ftp，Telnet，SMTP……

url和socket通信之间的区别是什么？

利用socket进行通信时，在服务器端运行一个socket通信程序。服务器端不停地监听某个端口，等待客户的连接申请，接到申请后建立连接并进行通信，所以，在socket通信方式中，服务器是主动等待连接通信的到来。

利用URL进行通信时，在服务器端常驻一个CGI程序，但它一直处于休眠状态。只有在客户端要求建立连接时才被激活，然后与用户进行通信。所以，在URL 通信方式中，服务器是被动等待连接通信的到来。

由于URL通信和socket通信的方式不同，所以，它们有各自的特点。

利用socket进行通信时，服务器端的程序可以打开多个线程与多个客户进行通信，还可以通过服务器使各个客户之间进行通信。这种方式比较灵活，适用于一些较复杂的通信，但是服务器端的程序必须始终处于运行状态以监听端口。

利用 URL进行通信时，服务器端的程序只能与一个客户进行通信，形式比较单一。但是它不需要服务器端的CGI程序一直处于运行状态，只是在有客户申请时才被激活。所以，这种方式比较适用于客户机的浏览器与服务器之间的通信。

SOCKET连接失败什么意思

在Internet上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。socket实质上提供了进程通信的端点。进程通信之前，双方首先必须各自创建一个端点，否则是没有办法建立联系并相互通信的。正如打电话之前，双方必须各自拥有一台电话机一样。在网间网内部，每一个socket用一个半相关描述: (协议，本地地址，本地端口) 一个完整的socket有一个本地唯一的socket号，由操作系统分配。

http和socket通信的区别

HTTP协议即超文本传送协议(Hypertext Transfer Protocol )，是Web联网的基础，也是手机联网常用的协议之一，HTTP协议是建立在TCP协议之上的一种应用。

HTTP连接最显著的特点是客户端发送的每次请求都需要服务器回送响应，在请求结束后，会主动释放连接。从建立连接到关闭连接的过程称为“一次连接”。

由于HTTP在每次请求结束后都会主动释放连接，因此HTTP连接是一种“短连接”，要保持客户端程序的在线状态，需要不断地向服务器发起连接请求。通常的做法是即时不需要获得任何数据，客户端也保持每隔一段固定的时间向服务器发送一次“保持连接”的请求，服务器在收到该请求后对客户端进行回复，表明知道客户端“在线”。若服务器长时间无法收到客户端的请求，则认为客户端“下线”，若客户端长时间无法收到服务器的回复，则认为网络已经断开.

socket:套接字（socket）是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含进行网络通信必须的五种信息：连接使用的协议，本地主机的IP地址，本地进程的协议端口，远地主机的IP地址，远地进程的协议端口。

套接字之间的连接过程分为三个步骤：服务器监听，客户端请求，连接确认.

它是一种“长连接”。

socket通信一般在用于哪里

从tcp socket通讯原理可以看到，在连接断开“四次挥手”过程中，只有被动close的一方才会出现CLOSE_WAIT和LAST_ACK，或者说如果发起close动作的看作client端，那出现CLOSE_WAIT和LAST_ACK就是server端。只要收到client端发出FIN包，server端就是CLOSE_WAIT状态，这个状态意味着可能在关闭连接之前还有许多数据要发送,如果没有数据要发送，那server就要回复一个FIN给cilent，然后server端就变成LAST_ACK，client收到server的FIN包后，正常会立即回复ACK，server只要收到ACK后连接就断开了。下面我们结合案例谈谈CLOSE_WAIT和LAST_ACK。

案例分析：

某系统的应用支持人员反馈，文件传输服务14029端口异常，业务被堵塞。我们登入系统检查，除文件传输服务交易处理缓慢，其他类型的交易均未受影响，也就是说该服务器有多个对外服务端口，只有一个端口异常。与应用开发人员沟通过后，反馈应用没有实施过变更。同时应用开发人员反映这类业务全部是从公网接入的，我们登入F5设备，将公网接入业务渐出后，交易并发请求量下降，文件传输服务端口堵塞现象逐渐缓解，但从F5重新渐入公网业务后，问题重现。

从异常时收集的数据分析，14029服务端口约有3000个连接，其中大多数连接处于CLOSE_WAIT和LAST_ACK状态。这么多的CLOSE_WAIT和LAST_ACK说明通讯阶段肯定不正常，看到这里，大家都怀疑问题出现网络层面了吧，这里先不回答，先结合上面介绍的TCP原理中的CLOSE_WAIT和LAST_ACK思考一下，现在问题仅反映出大量CLOSE_WAIT和LAST_ACK，连接建立阶段未出现异常，说明什么呢？继续查看网络通讯报文。异常时段的网络报文如下：

从网络报文看，连接释放前大致正常，为什么说大致正常，client和server有来有往，也无重传等异常现象，但是，交互一次经常有20多秒，所以只能说大致正常。在一笔交易完成后，开始断开连接，问题出现了，client端发出了FIN包，server立刻回复ACK，然后经过20多秒的等待后，又发送了长度为7的数据，再回复了FIN包，然后出现网络重传FIN包。

对于网络重传，乍一看以为是网络通讯丢包，但仔细一推敲，其他时间不丢包，为什么只在连接释放阶段丢包，没有道理啊。就此，我们和网络技术专家进行了沟通，得到的答复是：在通讯阶段，大量客户端超时发出连接关闭请求,也就是client发出了FIN包，server端服务进程处理超时未能及时响应关闭连接请求，超过10秒触发防火墙安全保护机制，连接关闭应答包（FIN）被防火墙抛弃，以至于出现大量FIN包重传的现象。答复就是说网络没问题，是应用程序超时了。

网络丢包问题排除了，那么问题可能就出在了应用程序上了，但应用程序的问题在哪里呢？我们回顾了前面的整个分析过程，有两个疑点和应用相关，一是通讯报文中客户端和服务端两端交互延时很大，经常出现20多秒时差；二是大量客户端发出断链请求。带着疑问，我们和应用开发人员进行沟通，进一步了解了交易的整个流程，很快第二个疑点就明确了，正常情况下，交易都是由农行端关闭，不会由公网客户端关闭，除非交易超时，从现象上看肯定出现了大量的客户端交易超时。同时从应用开发人员提供的交易流程分析，每一笔交易，分8次输出日志，也就是说一笔交易记录8次日志，对日志文件操作了8次。既然应用分步记录日志，那日志肯定能反映交易每一步的时间差，也就是说交易超时应用日志中能直接看出来。打开日志文件，发现日志文件中几乎很难看一笔完整的、顺序的日志，这是由于应用进程池多个进程并行写日志所致。这么重要的线索，怎么能随便放弃。为此我们根据日志中的时间戳以及进程号的规律专门编写了一个脚本负责遍历和排序近一周的应用日志，几个小时后，令人振奋的结果出来了，排序后的日志对每一笔交易时间记录很详细，大多数时间，每一笔交易都在一秒内完成，一到交易高峰，交易时间开始延迟，短的延迟2~3秒，长的延迟几十秒甚至上百秒，从日志可以推断出这个问题一直存在，只是反映出来程度轻重不同而已。

分析到这一步，应该是明确了应用程序存在问题，但应用程序的问题究竟是什么呢？有了方向，我们在业务高峰针对应用进程开启了truss跟踪，truss对交易的过程和底层调用非常详细记录如下：

交易中共有8次对于该日志的写入，以其中一次日志文件操作过程（kopen-kwrite-close）为例，其耗时达到1.1s以上。一笔交易完成，时间基本耗费都在10多秒。同时段，还有其他多个14029端口相关进程对于此日志并发操作，引起整笔中绝大多数都在进行该日志文件操作。从Truss信息中可以看到交易打开日志还是采用同步方式。

35782920: 48955803: 0.1007: kfork() = 18874542

18874542: kfork() (returning as child ...) = 0

18874542: 31785117: 0.1086: _getpid() = 18874542

35782920: 48955803: 0.1088: semget(1674622889, 1, 0)18874542: 31785117: 0.1088: thread_setmystate(0x00000000, 0x2FF21920) = 300942464 = 0

18874542: 31785117: 0.1091: _thread_self() = 31785117

18874542: 31785117: 0.1094: thread_setmystate(0x2FF21608, 0x2FF21910) = 0

18874542: 31785117: 0.1096: thread_setmymask_fast(0x00000000, 0x00000000, 0x00000000, 0xD051C880, 0x00000000, 0x11E5009D, 0x11E5009D, 0xF0256118) = 0x0000

0000

18874542: 31785117: 0.1104: thread_unlock(0x2003F750) = 0

18874542: 31785117: 8.0003: kopen("/ho22938062: 44761355: 8.0009: kopen("/home/beics/log/Fil = 83997862: 75104323: 8.0018: kopen

= 0 = 8 = 917170888: 63897901: 8.0034: close(9)16849568808: 53805667: 8.0037: kopen("/home/beics/log/FileSvr.20140604", O_RDWR|O_SYNC|O_APPE

= 0 = 9 = 932965182: 51970655: 8.0039: kopen("/home/beics/log/FileSvr.20140604", O_RDWR|O_SYNC|O_APPEND)35521118: 45220353: 8.0065: kopen("/home/b

eics/log/FileSvr.20140604", O_RDWR|O_SYNC|O_APPEND) = 8 = 98454202: 21954581: 8.0049: kopen("/home/beics/log/FileSvr.20140604", O_RDWR|O_SYNC|O_APPEND) = 91

5991212: 14877101: 8.0080: _erecv(7, 0x2FF21630, 7, 256, 0x00000000) = 76488658: 81134209: kwrite(8, 0x2FF208C4, 56) = 56

18874542: 31785117: kwrite(8, 0x2FF20B14, 53) = 53

18874542: [ 1 6 : 2 3 : 0 4 | 0 0 1 8 8 7 4 5 4 2 | ] ????[ 1 0 . *

18874542: . *. * ] ??????: Q U I T\n

分析到这里，相信大家知道怎么回事了，truss中多个线程并行操作，时间延迟了，信息都是乱的。所以，经过最终分析结论如下：由于交易过于频繁的、且使用同步方式对一个日志文件进行打开和写入操作，而这些文件操作都是串行操作，交易之间相互竞争记录日志，导致交易处理时间延长、处理效率下降。至于异常时系统层面看到的大量CLOSE_WAIT 和LAST_ACK，应该比较好理解，由于交易进程处理变慢，服务端接收到客户端发出的FIN包仍然在发送数据（响应前面的请求）所致，所以能看到很多CLOSE_WAIT；而LAST_ACK状态，是由于交易超时情况下，触发了防火墙安全机制，服务端回复的FIN被丢弃所致。

解决方案及建议：

应用开发人员在我们的建议下，对应用程序进行了优化，将打开文件方式改成异步方式，并改进了日志记录方法，每笔交易分步记入日志改成先缓冲、交易完成后一次性记入日志文件方式，降低操作日志文件的频率，减少文件操作竞争。优化完成后，该问题彻底解决。

socket通讯异常问题排查和处置难度大，系统层和应用层都也难以快速进行应急处置。建议架构上尽量采用集群模式，实现应用负载均衡，有效地规避应用"单点"风险，提升应用的高可用性。

对于自行开发的socket通讯系统，应用与TCP通讯关联紧密，异常处理机制都依赖应用实现，要详尽考虑外部环境的各种复杂异常情况，确实是非常困难的事情，就如一些业内经验丰富开发人员所说的，标准的socket通讯程序，3分功能代码，7分异常处置，如果缺乏这份决心，建议还是采用比较成熟的通讯中间件产品来实现通讯处理。

Socket通信与Http通信各有什么优缺点，谁快谁慢

socket是实现底层协议（tcp，udp等）的一个套接口。

http是基于tcp的应用层协议。

进程通讯中的socket和port的区别

进程通讯中的socket和port的区别

port：一种接口,数据通过它在计算机和其它设备(如打印机、鼠标、键盘或监视器)之间、网络之间或和其它直接连接的计算机之间传递。

什么是socket 所谓socket通常也称作"套接字"，用于描述IP地址和端口，是一个通信链的句柄。应用程序通常通过"套接字"向网络发出请求或者应答网络请求。

IP是英文Internet Protocol的缩写，意思是“网络之间互连的协议”，也就是为计算机网络相互连接进行通信而设计的协议。在因特网中，它是能使连接到网上的所有计算机网络实现相互通信的一套规则，规定了计算机在因特网上进行通信时应当遵守的规则。

socket通信问题

亲，不知道该说你对，还是你错。

服务器程序在一个端口监听，这个端口我们暂称为监听端口，当该端口收到新的请求链接时，服务器会创建一个新的端口来与客户通信，accept函数 不知道你熟悉不,你可以去看看msdn accept返回的就是新的socket 也就是与客户通信的套接字.这个新套接字的端口是随机的，不会通知客户端，因为没有必要；

客户端调用connect函数后 会向服务器发送链接请求，当服务器accept收到后，就会创建端口与客户端继续交互，创建套接字的这个过程对客户端来说完全是透明的. 这个端口仅仅负责这个链接的通信，（这时候大量的客户端向服务器的同一端口发送信息）所以你说的是错误的，监听端口是负责监听，就说你发数据它也不会处理。所以不存在（把接收的数据准确的分配到各个不同的会话中的)

还有你说对了一点 每当有一个新的链接时 服务器的确会分配一个端口与客户端通信，这个通信的过程不再走监听端口，监听端口是负责监听，不负责通信(收发数据)。每当一个新链接就创建一个线程来处理通信的话，太浪费资源，你可以参考下io完成端口讲的很详细。