socket是什么意思
SOCKET用于基于TCP/IP协议的两个应用之间的通信。它最早出现在UNIX系统中，是UNIX系统中信息传递的主要方式。在WINDOWS系统中，SOCKET被称为WINSOCK。
两个基本概念:客户和服务。当两个应用程序之间需要SOCKET通信时，需要在两个应用程序(可能位于同一台机器上，也可能位于不同的机器上)之间建立SOCKET连接，客户端发起呼叫连接请求，服务器接收呼叫连接请求。客户端和服务器相反，同一个应用可以是客户端，也可以是服务器。
在客户端调用连接请求之前，它必须知道服务器在哪里。所以需要知道服务器所在机器的IP地址或者机器名称。如果客户端和服务器事先有协议就好了，这个协议就是PORT。也就是说，客户端可以通过唯一确定服务方所在机器的IP地址或机器名称和端口号来呼叫服务方。客户端调用之前，服务端必须处于监听状态，监听是否有客户端请求建立连接。一旦接收到连接请求，服务提供商可以根据情况建立或拒绝连接。有两种连接模式，即阻塞和无阻塞。
客户端发送的消息可以是文本或二进制信息流。当来自客户端的消息到达服务端的端口时，会自动触发一个事件，服务端只要接手该事件就可以接受来自客户端的消息。
套接字服务器是什么意思
网络上的两个程序通过双向通信连接交换数据，通信连接的一端称为套接字。
建立网络通信连接至少需要一对端口号。套接字的本质是编程接口(API)。对于TCP/IP的封装，TCP/IP还为程序员提供了一个做网络开发的接口，就是Socket编程接口。HTTP是汽车，它提供了封装或显示数据的具体形式；Socket是一个引擎，提供网络通信的能力。
Socket的英文原意是“孔”或“插座”。作为BSD UNIX的进程通信机制，取后者的意思。俗称“socket”，用来描述IP地址和端口。它是通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。互联网上的主机一般运行多个服务软件，同时提供几种服务。每个服务都打开一个套接字，并绑定到一个端口。不同的端口对应不同的服务。插座在英语中的原意就像一个多孔插座。一台主机就像一个装满各种插座的房间，每个插座都有编号，有的插座提供220 V交流电，有的提供110 V交流电，有的提供有线电视节目。客户软件可以通过将插头插入不同号码的插座来获得不同的服务。
Socket和HTTP协议是什么关系？HTTP通信和socket通信有什么区别？
没错！
比喻:socket好比高速公路，HTTP就是在高速公路上行驶的汽车。除了HTTP，路上还有很多其他类型的车，Ftp，Telnet，SMTP……
url和socket通信有什么区别？
当使用套接字通信时，套接字通信程序在服务器端运行。服务器一直监听某个端口，等待客户的连接申请，收到申请后建立连接并通信。因此，在套接字通信模式下，服务器主动等待连接通信的到达。
在使用URL通信时，一个CGI程序驻留在服务器端，但总是处于休眠状态。只有当客户端请求建立连接，然后与用户通信时，它才会被激活。因此，在URL通信模式下，服务器被动等待连接通信的到来。
因为URL通信和socket通信不同，所以有各自的特点。
使用socket通信时，服务器端的程序可以打开多个线程与多个客户进行通信，也可以通过服务器与每个客户进行通信。这种方法很灵活，适合一些复杂的通信，但是服务器端的程序必须一直运行才能监听端口。
使用URL通信时，服务器端程序只能与一个客户端通信，形式相对简单。但是它不需要服务器上的CGI程序一直运行，只有在有客户应用的时候才激活。因此，这种方法更适合客户端浏览器和服务器之间的通信。
SOCKET连接失败是什么意思
互联网上的主机一般运行多个服务软件，同时提供几种服务。每个服务都打开一个套接字，并绑定到一个端口。不同的端口对应不同的服务。套接字本质上提供了进程通信的端点。在进行通信之前，双方必须首先创建一个端点，否则就没有办法建立联系和相互通信。就像之前打电话一样，每一方必须拥有一部电话。在网际网络中，每个套接字使用一个半相关的描述:(协议、本地地址、本地端口)一个完整的套接字有一个本地唯一的套接字号，它是由操作系统分配的。
http和套接字通信的区别
HTTP协议，即超文本传输协议，是Web联网的基础，也是手机联网常用的协议之一。HTTP协议是基于TCP协议的应用。
HTTP连接最显著的特点是客户端发出的每一个请求都需要服务器发回一个响应，请求完成后连接会自动释放。从建立连接到关闭连接的过程称为“一次性连接”。
HTTP连接是一种“短连接”，因为它会在每次请求后主动释放连接。为了保持客户端程序在线，有必要不断地向服务器发送连接请求。通常的做法是，客户端不需要立即获取任何数据，客户端定期不断地向服务器发送“保持连接”的请求。服务器收到请求后回复客户端，表示知道客户端“在线”。如果服务器长时间没有收到客户端的请求，则认为客户端“离线”，如果客户端长时间没有收到服务器的回复，则认为网络已经断开。
Socket: socket是通信的基石，是支持TCP/IP协议的网络通信的基本操作单元。它是网络通信过程中端点的抽象表示，包含网络通信所需的五种信息:连接协议、本地主机的IP地址、本地进程的协议端口、远程主机的IP地址和远程进程的协议端口。
套接字之间的连接过程分为三个步骤:服务器监听、客户端请求和连接确认。
是一种“长连接”。
套接字通信通常在哪里使用
根据tcp套接字通信原理，只有被动关闭方会在连接断开的“四波”过程中出现CLOSE_WAIT和LAST_ACK，或者如果客户端发起关闭动作，那么服务器端会出现CLOSE_WAIT和LAST_ACK。只要接收到客户端发送的FIN包，服务器就会处于CLOSE_WAIT状态，这意味着在连接关闭之前可能会有很多数据要发送。如果没有要发送的数据，服务器将向客户端回复一个FIN，然后服务器将成为最后一个确认。客户端收到服务器的FIN包后，会立即回复ACK，服务器一收到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，连接建立阶段没有异常。什么意思？继续查看网络通信消息。异常期间的网络消息如下:
根据网络消息，释放前连接一般正常。为什么普遍正常？客户端和服务器来来去去，没有出现重传等异常现象。但是互动往往一次需要20秒以上，所以只能说一般正常。事务完成后，连接开始断开，问题出现了。客户端发出一个FIN包，服务器立即回复一个ACK。等待超过20秒后，发送长度为7的数据，然后回复FIN包，然后网络重传FIN包。
对于网络重传，乍看起来是认为网络通信丢包，但仔细推敲，其他时间不丢包，所以只在连接释放阶段丢包是没有意义的。对此，我们与网络技术专家进行了沟通，得到的答案是:在沟通阶段，随着时间的推移，大量客户端发出了关闭连接请求，即客户端发出了FIN包，服务器端服务流程未能及时响应关闭连接请求，触发防火墙安全保护机制超过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()(作为孩子返回...) = 0
18874542:31785117:0.1086:_ getpid()= 18874542
35782920:48955803:0.1088:semget(1674622889，1，0)18874542:31785117:0.1088:thread _ setmystate(0x 0000000，0x2FF21920) = 300942464 = 0
18874542:31785117:0.1091:_ thread _ self()= 31785117
18874542:31785117:0.1094:thread _ setmystate(0x2ff 21608，0x2FF21910) = 0
18874542:31785117:0.1096:thread _ setmymask _ fast(0x00000000、0x0000000、0x0000000、0xD051C880、0x 0000000、0x11E5009D、0x11E5009D、0xF0256118) = 0x0000
0000
18874542:31785117:0.1104:thread _ unlock(0x 2003 f 750)= 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/FileVR . 20140604 "，O _ RDWR | O _ SYNC | O _ APPEND)35521118:45220353:8.0065:kopen("/home/b
eics/log/FileVR . 2014 06 04 "，O _ RDWR | O _ SYNC | O _ APPEND)= 8 = 98454202:21954581:8.0049:kopen("/home/beics/log/FileVR . 2014 06 04 "，O_RDWR|O_SYNC|O_APPEND) = 91
5991212:14877101:8.0080:_ erecv(7，0x2FF21630，7，256，0x 0000000)= 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
分析完这些，相信大家都知道发生了什么。桁架中多个线程并行操作，时间延迟，信息混乱。因此，经过最终分析，结论如下:由于事务过于频繁，并且以同步方式打开和写入一个日志文件，而这些文件操作都是串行操作，事务相互竞争记录日志，导致事务处理时间延长，处理效率降低。至于交易流程异常时在系统层面看到的大量CLOSE_WAIT和LAST_ACK，应该很好理解，服务器能看到大量close _ wait是因为客户端发送的FIN包还在发送数据(响应之前的请求)；LAST_ACK状态是由于防火墙安全机制被触发，事务超时时服务器回复的FIN被丢弃造成的。
解决方案和建议:
在我们的建议下，应用开发人员优化了应用程序，将文件打开模式改为异步模式，并改进了日志记录方法。每个事务都是先逐级记入缓冲模式，事务完成后再记入日志文件一次，降低了操作日志文件的频率和文件操作的竞争。优化后，问题彻底解决。
异常套接字通信问题很难检查和处理，系统层和应用层都很难快速处理突发事件。建议尽可能采用集群模式实现应用负载均衡，有效避免应用“单点”风险，提高应用高可用性。
对于自主开发的socket通信系统，应用与TCP通信密切相关，异常处理机制取决于应用实现。详细考虑外部环境中的各种复杂异常确实非常困难。正如业内一些经验丰富的开发人员所说，标准套接字通信程序有三个功能代码和七个异常处理。如果没有这样的确定，建议采用更成熟的通信中间件产品来实现通信处理。
Socket通信和Http通信各有什么优缺点，哪个更快哪个更慢
Socket是一个windows sockets，实现底层协议(tcp，udp等)。).
Http是基于tcp的应用层协议。
进程通信中套接字和端口的区别
进程通信中套接字和端口的区别
端口:一种接口，通过它可以在计算机和其他设备(如打印机、鼠标、键盘或显示器)之间、网络之间或直接相互连接的计算机之间传输数据。
什么是socket？套接字通常被称为“套接字”，用于描述IP地址和端口，是通信链的句柄。应用程序通常通过“套接字”向网络发送请求或回答网络请求。
IP是英文互联网协议的缩写，意思是“网络之间的互连协议”，即为计算机网络相互通信而设计的协议。在互联网中，它是一套可以使所有连接到互联网的计算机网络相互通信的规则，规定了计算机在互联网上通信时应该遵守的规则。
套接字通信问题
亲爱的，我不知道你是对是错。
服务器程序在端口监视器中。这个端口暂时称为监听端口。当端口接收到新的请求链接时，服务器将创建一个新的端口来与客户端通信。accept函数不知道你是否熟悉。您可以去看看msdn accept返回的新套接字是与客户端通信的套接字。这个新套接字的端口是随机的，不会通知客户端，因为它是不必要的。
客户端调用connect函数后，会向服务器发送链接请求。当服务器接受它时，它将创建一个端口来继续与客户端交互。创建套接字的过程对客户端是完全透明的。该端口仅负责该链路的通信。(此时，大量客户端向服务器的同一端口发送信息。)所以你说的不对。监听端口负责监听，所以不会处理你发送的数据。所以它不存在(接收的数据被精确地分配到不同的会话)
还有，你是对的。只要有新的链接，服务器就会分配一个端口与客户端通信。通信过程中不再使用监控端口。监控端口负责监控，不负责通信(发送和接收数据)。每次一个新的链接创建一个线程来处理通信，都是资源的浪费。详情可参考io完成端口。