What are the differences between SMTP and TCP handshaking? Why is SMTP handshaking important?
A TCP handshake happens at the transport layer of the TCP/IP protocol stack, involving signaling using TCP flags, TCP sequence numbers, TCP port numbers and IP addresses.
SMTP handshaking occurs at the application layer of the TCP/IP protocol, above the transport layer. SMTP handshaking is rarely called a handshake and is composed of the server sending a 220 message representing its banner, the client sending an EHLO or a HELO message along with its name, to which the server will respond with a 220 message indicating success. Subsequent to this the actual email exchange begins.
You can read more about this in RFC 5321.
Related
We have a real server behind the proxy server (or a firewall). The client must connect to the real server through IPSec Transport mode Encryption. The IPSec Transport mode works between the two hosts and fails whenever a hop is introduced between the two hosts. This is due to Checksum Integrity failure at the destination which is due to DNAT at the intermittent hop between 2 hosts.
We want something to encapsulate the ESP Transport mode packet either in an IP Header or UDP encapsulation or something like this ->
A --------------------> GATEWAY --------------------> B
Transport (Transport mode is received Packet
and IP header is accepted
encapsulated on the packet
and is forwarded again)
Is something like this possible where the Client sends the Transport mode ESP packet and the intermittent hosts encapsulate that packet (either in IP/UDP) and then send it to the destination?
Is there any RFC for these types of scenarios?
Let say I have a server XYZ that listens on port 50000 for TCP clients and port 80 for HTTP clients. And on the other side, I have a client that uses a WebSocket to establish a socket connection to port 50000 and will use HTTP port 80 for the handshake (of course).
Now, when the client begins, it will first send a request to server XYZ via the HTTP port 80, and the server will receive its request on port 80 for the handshake and will send a response for welcome. So, in that case, both parties are using port 80 (of course).
Now, when the handshake is done, the standard documentation says that the same TCP connection that is used for HTTP request/response for handshake purposes is then converted to the TCP socket connection. Ok right.
But, but if this whole handshake process and TCP connection for the HTTP request/response uses port 80 the first time, and that the same TCP connection is converted to the TCP socket connection, and this whole process is done via port 80, then how does the same TCP connection get converted to port 50000 for the TCP socket on both parties? Does the client initialize another TCP connection internally for changing to port 50000?
So, can anyone tell how the port conversion is performed and works in the WebSocket from port 80 to a different port in both parties? How does a complete single socket connection get established on the different ports? How does the same TCP connection change/flip its ports?
A TCP socket connection cannot change ports at all. Once a connection has been established, its ports are locked in and cannot be changed. If you have a TCP socket connection on port 80, the only way to have a connection on port 50000 is to make a completely separate TCP socket connection.
A WebSocket cannot connect to port 80 and then switch to port 50000. However, an HTML page that is served to a browser from port 80 can contain client-side scripting that allows the browser to make a WebSocket object and connect it to port 50000. The two TCP connections (HTTP and WebSocket) are completely separate from each other (in fact, the HTTP socket connection does not even need to stay open once the HTML is served, since HTTP is a stateless protocol).
I am trying to capture the packets moving from my system when i searched URL www.google.com in the browser. This is the flow I am seeing in wireshark.
DNS request was made
TCP three-way handshake is done
TLSV1.2 handshake has started.
In between tlv1.2 handshake I am seeing TCP packets moving from my system to the same port. What is that traffic regarding? I am sharing the screenshot for the same.
The TCP packets with description "ACK" are TCP acknowledgement packets.
An acknowledgement packet is sent to the server for each time the client receives a TCP data packet from the server.
The TCP packets with description "TCP segment of a reassembled PDU" are TCP fragmented data packet.
TCP may divide an upper layer packet into multiple packets. A TCP fragmented data packet is a piece of a divided packet.
For example, the TLS server certificate packet (#1842) was divided into 3 packets by TCP, #1839, #1841, and #1842.
Which software libraries does exist for such task for Linux, Windows OS?
Does it exist some info in RFC how people should do it?
I'm interesting how can I create functionality for my C++ project like presented here in that software: https://secure.logmein.com/ru/products/hamachi/download.aspx
There is not much difference if you want to make a connection through TURN relay server. The only difference is how TCP and UDP creates connection and nothing else.
There are some big differences if you want to make P2P connection.
If you are in same network(behind same NAT): In UDP you send a stun binding request to your peer candidate and then if you get a response back then you know you are connected. Same in TCP you have to create one active socket on one side and one passive socket on another. And then send syn from active socket and receive it from passive socket and then send syn ack to the active socket. And then active socket send an ack and the connection is established.
If you are in different Network(behind different NAT): You have to employ TCP hole punching technique for making a connection. Because your NAT won't allow a TCP syn packet through if previously no packet was sent to the address the syn is coming from.
TCP hole punching in details:
You have to use a TCP simultaneous open socket. This socket acts in both active and passive mode. Both end needs to know each others private and public IP:Port.
TCP simultaneous open will happen as follows:
Peer A keeps sending SYN to Peer B
Peer B keeps sending SYN to Peer A
When NAT-a receives the outgoing SYN from Peer A, it creates a mapping in its state machine.
When NAT-b receives the outgoing SYN from Peer B, it creates a mapping in its state machine.
Both SYN cross somewhere along the network path, then:
SYN from Peer A reaches NAT-b, SYN from Peer B reaches NAT-a
Depending on the timing of these events (where in the network the SYN cross),
at least one of the NAT will let the incoming SYN through, and map it to the internal destination peer
Upon receipt of the SYN, the peer sends a SYN+ACK back and the connection is established.
From WIKI.
Also to learn about TCP simultaneous open connection read from here. To learn about NAT filtering behavior see this answer.
when a TCP client wants to establish a tcp connection with a tcp server
it needs to send SYN and then ACK
while tcp server only sends SYN/ACK
so they are different
but , after the 3_way handshaking,
is this connection symmetric, namely, are TCP client and server in equal status
for example, after the 3-way handshake, usually the client send packet first,
can TCP server send packet first?
No, the procedure is not different at all, but instead of sending a SYN then an ACK in two different packets, the servers concatenate them by sending them via a single packet!
In the other hand, remember always that the client/server nomenclature is relative. The server is the party that remains in listening mode, while the client is the party that initiates the connection ...
After the establishment of the connection, both parties are equivalent (same status as you said: ESTABLISHED). For that reason, both can send the FIN statement to close the connection ...
After the connection is established, both ends are indeed "symmetric". Who sends first is decided by the underlying protocol and differes amongst them.
For example, HTTP starts with the GET <path> HTTP/1.0 command, while other protocols let the server give a greeting line first, and only then the client sends its request.
So in general, both ends are free to send their stuff first.