We know that before sending information, TCP has to establish a connection with another host. So, does the request from TCP get encapsulated by lower levels of stack protocols or is it just sent directly to another host?
If I'm not mistaken, it looks like the confusion that the OP has is not with ordinary TCP data traffic once the TCP connection is established, but the TCP control signaling.
The OP writes
before sending information, TCP has to establish a connection with another host
which looks like the context, followed by:
So, does the request from TCP get encapsulated by lower levels of stack protocols or is it just sent directly to another host?
So the question is, for the connection establishment signalling, is that also encapsulated by lower layers of the protocol stack (as is what happens in normal TCP data traffic), or is it sent directly, without the need for the encapsulation by lower layers?
The answer is, yes. Consider the SYN segment in the 3-way handshake for TCP connection establishment. It is like an ordinary TCP segment except for a few important differences (e.g., see RFC 793):
- There are 6 control bits every TCP header, one of which is for SYN. In a SYN segment, that bit would be set.
- There is a 32-bit sequence number in every TCP header. This is normally the sequence number of the first data octet in this segment, except for the SYN segment. In the case of SYN, the sequence number is the initial sequence number (ISN).
- Rather than carrying actual data in the data octets, for SYN, it is specified that "the first data octet is ISN+1"
So why can't the special segments like SYN in the 3-way handshake be sent "directly", bypassing the lower layers? We cannot send them directly, as the IP layer below would not know how to route these TCP control signalling segments! Sure, we could have invented some other ways to do the routing in a different way for these segments, but we already have the IP layer with IP routing and encapsulation of TCP segments, and that works well for packet delivery, so we just re-use all that infrastructure.
Actually, a request is something that only exists in the application layer, like an HTTP GET request. That request is encapsulated by a TCP segment (or multiple ones).
Each TCP segment (transport layer) is encapsulated in an IPv4 or IPv6 packet (network layer). Each IP packet is in turn encapsulated in e.g. an Ethernet frame (link layer). An Ethernet frame is line encoded and sent over the wire as bits or symbols (physical layer).
The process reverses on the other side and the GET request is recovered.
 An IP packet may be fragmented and transported using multiple frames when it is too large to fit into a single frame (MTU).
So each layer is separate from each other in the OSI model. If you take an HTTP request/response it’s basically a string of bytes sent and then a string of bytes received. This is wrapped in a tcp header with, amongst other things, source and destination IP. This is then, in the case of Ethernet, wrapped in an Ethernet frame (with a source and destination MAC address) and put on the wire. A receiving device will pick it up if the destination matches its own mac and unwrap the frame. Then depending on if it’s a router than needs to forward the tcp packet it might rewrap that in another frame and send it to another device or if it is the end host and matches the destination IP then it will use the destination port to pass the contents of the packet to the correct application.
When it comes to TCP protocal before connection initiate TCP handshake will initiate . TCP syn & syn ack &ack handshake complete . The. SSL handshake begins after SSL handshake completes actuall application data will be transferred in encrypted format. As TCP is reliable protocal. If any packet in queue is waiting entire queue will be waiting because in TCP new packet will be intimated after receiving acknowledgement for old packet .
When it comes to udp packet it's non realible protocol. All voice communication comes under udp protocol