Recently, I am learning Flink to simulate real-time data through NC. However, when you enter NC -lk 7777 under windows, the following error is reported:
C:\Users\7371>nc -lk 7777
nc: invalid option -- k
nc -h for help
After some searching, it was finally solved
windows is different from Linux. You can enter NC - L - P 7777 directly after CMD
Problem recurrence:
<?php
function getCertInfo($domain)
{
$context = stream_context_create([
'ssl' => [
'capture_peer_cert' => true,
'capture_peer_cert_chain' => true,
],
]);
$client = stream_socket_client("ssl://{$domain}:443", $errorCode, $errorMessage, 30, STREAM_CLIENT_CONNECT, $context);
if ($client === false) {
var_dump("!!!open {$domain} socket connection fail. {$errorMessage}($errorCode) !!!";
return false;
}
$params = stream_context_get_params($client);
if (empty($params['options']['ssl']['peer_certificate'])) {
var_dump("!!!{$domain} stream_context_get_params options ssl peer_certificate is empty!!!");
return false;
}
return openssl_x509_parse($params['options']['ssl']['peer_certificate']);
}
Solution: $context add verify_ Peer configuration
<?php
$context = stream_context_create([
'ssl' => [
'capture_peer_cert' => true,
'capture_peer_cert_chain' => true,
'verify_peer' => false,
],
]);Basic idea of select
Set LFD as port reuse
The file descriptors that need to be monitored are sent to the kernel for listening through select. When an event occurs, the number of events is returned through select. Then scan the set of file descriptors one by one to process the event.
Include file:
< sys/select.h>
The function structure of select is as follows:
int select(int nfds, fd_ set * readfds, fd_ set *writefds, fd_ set *exceptfds, struct timeval *timeout);
Parameter description
fd_ Set: the structure of file descriptor set. It is a 1024 bitmap. 0 means that there is no event and 1 means that there is an event. The converted format is:
typedef struct
{
long int__ fds_ bits[1024/(8*8))];
}
NFDS: the maximum number of file descriptors being monitored is + 1
readfds: read set is an incoming and outgoing parameter. The incoming parameter is the set of file descriptors that need to be read and monitored, and the outgoing parameter is the changed file descriptor<
writefds: write file descriptor (same as above, incoming and outgoing parameters)
execptfds: exception file descriptor (same as above, incoming and outgoing parameters)
timeout:
0: no blocking, return immediately after scanning
greater than 0: blocking waiting time is long, return immediately when no event occurs before arrival time
null: permanent blocking wait event
Return:
– 1: listening failure
greater than 0: number of events
Correlation bit operation
1. Remove FD from set
void FD_ CLR(int fd,set *set);
2. Judge whether the descriptor is in the set
2_ ISSET(int fd,fd_ set *set);
3. Put descriptors into the set
void FD_ SET(int fd,fd_ Set * set)
4. Empty set
void FD_ ZERO(fd_ set *set)
Advantages and disadvantages of select
Advantages: cross platform, supported on both windows and Linux
disadvantages: it involves copying back and forth between user area and kernel area. When there are many links but few active users, the efficiency is low, and the maximum number of listeners can not exceed 1024.
Select code
Insert code snippet here
#include<sys/types.h>
#include<stdio.h>
#include<stdlib.h>
#include<string.h>
#include<unistd.h>
#include<arpa/inet.h>
#include<netinet/in.h>
#include<ctype.h>
#include<sys/socket.h>
#include<sys/select.h>
#include<iostream>
#include<string>
using namespace std;
int main()
{
/*1.create socket*/
int lfd=socket(AF_INET,SOCK_STREAM,0);
if(lfd<0)
{
perror("socket error!");
return -1;
}
/*Setting up port multiplexing*/
int opt=1;
setsockopt(lfd,SOL_SOCKET,SO_REUSEADDR,&opt,sizeof(int));
/*Initialize server-side address structure*/
struct sockaddr_in sevr;
bzero(&sevr,sizeof(sevr));
sevr.sin_family=AF_INET;
sevr.sin_port=htons(9090);
sevr.sin_addr.s_addr=htonl(INADDR_ANY);
/*Binding socket address structure*/
int ret=bind(lfd,(sockaddr *)&sevr,sizeof(sockaddr));
if(ret<0)
{
perror("bind error!");
return -1;
}
/*Listening to events*/
int re= listen(lfd,128);
/*Create a collection of listened read events*/
fd_set readfds;
fd_set tmpfds;
/*Initialization*/
FD_ZERO(&readfds);
FD_ZERO(&tmpfds);
/*Adding file descriptors to the read event set*/
FD_SET(lfd,&readfds);
int maxfd=lfd+1;
int cfd;
while(1)
{
tmpfds=readfds;
/*Give the event descriptors in the collection to the kernel to listen */
/* Listening range, max file descriptors + 1*/
int nready=select(maxfd+1,&tmpfds,NULL,NULL,NULL);
cout<<nready<<endl;
if(nready<0)
{
/*Event Terminal*/
if(errno==EINTR)
continue;
cout<<"select error"<<endl;
break;
}
/*There is a client connection request*/
if(FD_ISSET(lfd,&tmpfds))
{
cfd=accept(lfd,NULL,NULL);
if(cfd<=0)
{
cout<<"accept error"<<endl;
return -1;
}
/*Add cfd to the listener set */
FD_SET(cfd,&readfds);
/*Modify the value of maxfds*/
if(maxfd<=cfd)
{
maxfd=cfd;
}
/* Only listen events, no read content events*/
if(--nready==0)
{
cout<<"continue"<<endl;
continue;
}
}
/*Polling to find out the descriptors of read events*/
for(int i=0;i<=maxfd;i++)
{
cout<<i <<endl;
if(FD_ISSET(i,&tmpfds))
{
cout<<"is in cfds"<<endl;
char buf[1024]={0};
int n=read(i,buf,sizeof(buf));
if(n<=0)
{
/*close*/
cout<<"read error"<<endl;
close(i);
/*dele*/
FD_CLR(i,&readfds);
}
else
{
cout<<buf<<endl;
for(int k=0;k<n;k++)
{
buf[k]=toupper(buf[k]);
}
write(i,buf,n);
}
}
}
}
close(lfd);
close(cfd);
return 0;
}
Symptoms:
Action.c(16): Error : socket0 – Software caused connection abort. Error code : 10053.
Server Listen–>
Server Listen–> Client Connect–> Server Accept –> Client Send –> Server Recv–> Client Close –> Server Close
if you do not take the initiative to Close the connection and direct to withdraw from the Client end, Server end service thread will cause a 10053 error (this kind of error usually effect is not too big), and if in the process of the communication Server first initiative to Close the connection, the Client end can also cause a 10053 error
the situation of the bad network is usually refers to the latter, the Client thought the Server off (the actual network broken), so I cried. “10053
Recently, when I used LoadRunner to conduct the performance test of Winsock protocol, the WebServer tested was JBoss, and 10053 errors often occurred. The phenomenon was as follows: after I created the connection with lrs_create_socket, when the number of requests for this socket connection reached 100, the connection was not available, and it had to be closed before creating again. LoadRunner causes Connection abort. Error code: 10053. LoadRunner causes Connection abort.
After much exploration, it was finally found that the error was due to the configuration of the HTTP 1.1 KeepAlive parameter in Apach HTTPServer. From my test results of several different Webservers, it can be seen that JBoss and Tomcat made errors when a Socket connection made 100 requests, while other Web servers, such as IIS and WebLogic, did not have this problem.
several related parameters are described below: KeepAlive, KeepAliveTimeout, and MaxKeepAliveRequests.
KeepAlive Directive
Description: Enables HTTP persistent connections
Syntax: KeepAlive On|Off
Default: KeepAlive On
Context: server config, virtual host
Status: The Core
Module: the Core
In HTTP 1.0, a connection can only transfer one HTTP request, while the KeepAlive parameter is used to support the one connection, multiple transfers feature of HTTP 1.1, so that multiple HTTP requests can be passed in one connection. Although only newer browsers support this feature, this option is enabled anyway.
The keep-alive extension to HTTP/1.0 and The Persistent Connection feature of HTTP/1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some The Keep Alive Extension to HTTP/1.0 and The Persistent Connection feature of 1.1 provide long-lived HTTP sessions which allow multiple requests to be sent over The same TCP Connection.In some cases this has been shown to result in an almost 50% speedup in latency times for HTML documents with many images. To enable Keep-Alive connections, set KeepAlive On.
For HTTP/1.0 clients, keep-alive Connections will only be used if they are specifically required by a client. In addition, A keep-alive connection with an HTTP/1.0 client can only be used when the length of the content is known in advance. This implies that dynamic content such as CGI output, SSI Pages, And server-generated Directory listings will generally not use keep-alive Connections to HTTP/1.0 clients.for HTTP/1.1 clients, persistent connections are the default unless otherwise specified. If the client requests it, chunked encoding will be used in order to send content of unknown length over persistent connections.
— — — — — — — — — — — — — — — — — — — — — —
KeepAliveTimeout Directive
Description: Amount of time the server will wait for subsequent requests on a persistent connection
Syntax: KeepAliveTimeout
Default: KeepAliveTimeout 15
Context: server config, virtual host
Status: Core
Module: Core
KeepAliveTimeout tests the time between multiple request transfers in a single connection. If the server has completed one request but has not received the next request from the client, the server disconnects after the interval exceeds the value set by this parameter.
The number of seconds Apache will wait for a subsequent request before closing the connection. Once a request has been received, the timeout value specified by the Timeout directive applies.
Setting KeepAliveTimeout to a high value may cause performance problems in heavily loaded servers. The higher the timeout, the more server processes will be kept occupied waiting on connections with idle clients.
— — — — — — — — — — — — — — — — — — — — — —
MaxKeepAliveRequests Directive
Description: Number of requests allowed on a persistent connection
Syntax: MaxKeepAliveRequests Number
Default: MaxKeepAliveRequests 100
Context: Virtual host
Status: Core
Module: Core
MaxKeepAliveRequests is the maximum number of HTTP requests that can be made with a single connection. Setting its value to 0 will support an unlimited number of transfer requests within a single connection. In fact, no client requests too many pages in a single connection, and usually the connection is completed before this limit is reached.
The MaxKeepAliveRequests directive limits the number of requests allowed per connection when KeepAlive is on. If it is set to 0, unlimited requests will be allowed. We recommend that this setting be kept to a high value for maximum server performance.
For example:MaxKeepAliveRequests 500
Finally, although this problem was caused by the parameter configuration of HTTPServer, only LoadRunner would have had this problem, and if Rational Robot had implemented the same functionality, it would not have had this problem, presumably due to the testing tool’s implementation strategy for Socket connections.
One of the most common mistakes in socket programming is the ECONNRESET error that I mentioned in this article. Another mistake that is rarely encountered is the EPIPE error that I will talk about today. This error can occur when sending data when the send function is called, and the program throws the following exception:
socket.error: [Errno 32] Broken pipe
Why this error?First, take a look at the official man 2 write document describing this error:
EPIPE
fd is connected to a pipe or socket whose reading end is closed. When this happens the writing process will also receive a SIGPIPE signal. (Thus, the write return value is seen only if the program catches, blocks or ignores this signal.)
Above, when writing data to a closed reader pipe or socket, the program receives a SIGPIPE signal. We have seen the example of a pipeline in this article.
Today, we’ll take a simple socket example to explore why this error occurs.
The client code is as follows:
import socket
import time
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 2222))
s.send('hello')
time.sleep(1)
s.send('hello')
s.send('hello')
s.close()
The server code is as follows:
import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
s.bind(('127.0.0.1', 2222))
s.listen(5)
c, addr = s.accept()
c.recv(1024)
c.close()
After 1 second of running the client program, the Broken pipe error occurs:
[root@localhost python]# python client.py
Traceback (most recent call last):
File "client.py", line 10, in <module>
s.send('hello')
socket.error: [Errno 32] Broken pipe
The results are as follows:
03:51:51.137047 IP 127.0.0.1.50870 > 127.0.0.1.2222: Flags [S], seq 2737957170, win 32792, options [mss 16396,sackOK,TS val 39403123 ecr 0,nop,wscale 5], length 0
03:51:51.137055 IP 127.0.0.1.2222 > 127.0.0.1.50870: Flags [S.], seq 2751472309, ack 2737957171, win 32768, options [mss 16396,sackOK,TS val 39403123 ecr 39403123,nop,wscale 5], length 0
03:51:51.137061 IP 127.0.0.1.50870 > 127.0.0.1.2222: Flags [.], ack 1, win 1025, options [nop,nop,TS val 39403123 ecr 39403123], length 0
03:51:51.137083 IP 127.0.0.1.50870 > 127.0.0.1.2222: Flags [P.], seq 1:6, ack 1, win 1025, options [nop,nop,TS val 39403123 ecr 39403123], length 5
03:51:51.137089 IP 127.0.0.1.2222 > 127.0.0.1.50870: Flags [.], ack 6, win 1024, options [nop,nop,TS val 39403123 ecr 39403123], length 0
03:51:51.137158 IP 127.0.0.1.2222 > 127.0.0.1.50870: Flags [F.], seq 1, ack 6, win 1024, options [nop,nop,TS val 39403123 ecr 39403123], length 0
03:51:51.139348 IP 127.0.0.1.50870 > 127.0.0.1.2222: Flags [.], ack 2, win 1025, options [nop,nop,TS val 39403137 ecr 39403123], length 0
03:51:52.140421 IP 127.0.0.1.50870 > 127.0.0.1.2222: Flags [P.], seq 6:11, ack 2, win 1025, options [nop,nop,TS val 39404140 ecr 39403123], length 5
03:51:52.140444 IP 127.0.0.1.2222 > 127.0.0.1.50870: Flags [R], seq 2751472311, win 0, length 0
It was observed that the error occurred as follows:
send to send data causes the socket to receive RST message. The second call send and then send the data causes the program to receive the SIGPIPE signal, and the Broken pipe error occurs. Therefore, we can draw the conclusion that if the opposite end closes the connection normally and then RST message is received on the socket, then when send is called on the socket, the Broken pipe error will occur!
This error is usually caused by a bug in the program code, but it is not a serious error and can usually be avoided by ignoring the SIGPIPE signal.
[ERROR: Socket Hang up] code: ‘ECONNRESET’}
Analysis reason: For some reason, the HTTP target address establishment socket connection error
Error resolution: After
Compared with the search, I found that there was a use of the middleware “body-parser” in the NodeJS project here, so there is no problem to remove it
There are other reasons that I haven’t come across here, but I won’t go into them,
In this way, if the send fails, it can return immediately, and the server won’t be stuck there.
At this time, if the send is unsuccessful, the return value of the send is error 10035.
Then I checked the test client and realized that my client did not receive at all.
That’s weird.