WEBVTT

00:01.030 --> 00:07.090
Transmission control protocol operates in various states throughout the life cycle of a connection.

00:07.120 --> 00:12.640
Understanding these states is crucial for analyzing network traffic and troubleshooting connectivity

00:12.670 --> 00:13.330
issues.

00:13.360 --> 00:16.420
Now let's delve deeper into the TCP state.

00:16.450 --> 00:23.770
The first lesson in this state, The system is waiting for connection requests from a remote host,

00:23.770 --> 00:29.140
and it typically occurs on servers that are ready to accept incoming connection.

00:30.230 --> 00:31.940
Synchronize send.

00:31.970 --> 00:40.040
After the client initiates a connection request by sending synchronized packet, it enters the synchronized

00:40.040 --> 00:45.230
send state and the client waits for a response from the server in that state.

00:46.530 --> 00:47.970
Sin received.

00:47.970 --> 00:55.710
When the server receives this packet, it sends back the synchronized acknowledge packet to the clients

00:55.710 --> 00:56.250
request.

00:56.400 --> 01:04.770
So the server then enters the synchronized received states waiting for the final knowledge from the

01:04.770 --> 01:07.020
client established.

01:08.210 --> 01:14.870
Once a client receives a synchronized acknowledged packet, it sends the acknowledged packet to the

01:14.870 --> 01:18.780
server and indicating that the connection is established.

01:18.800 --> 01:25.970
Both the client and server enter the established state loving bidirectional communication.

01:27.480 --> 01:34.320
Finweight won when one side of the connection wishes to terminate the session, it sends a thin packet

01:34.320 --> 01:36.230
to initiate the closure.

01:36.240 --> 01:43.020
The side sending the thin packet enters the finweight one state waiting for acknowledgement from the

01:43.020 --> 01:43.980
other side.

01:44.910 --> 01:45.960
Thin weight, too.

01:46.080 --> 01:52.710
After sending the thin packet, the side initiating the termination enters the thin weight two state.

01:52.740 --> 01:58.170
It waits for a thin packet from the remote host to confirm the termination request.

01:59.350 --> 02:00.460
Claws weight.

02:00.580 --> 02:05.640
When one side receives a fin packet from the other side, it enters the claws.

02:05.650 --> 02:06.580
Wait state.

02:06.610 --> 02:09.040
The side acknowledges the.

02:10.000 --> 02:15.160
Termination request and waits for the own application to close the connection.

02:15.770 --> 02:18.350
Closing in the closing state.

02:18.380 --> 02:24.170
A host has sent thin packet and is in the process of closing the connection.

02:24.170 --> 02:29.090
It waits for acknowledgement from the remote host to complete the closure.

02:29.990 --> 02:36.710
Last acknowledgement, after receiving a thin packet and sending its acknowledgement, the host enters

02:36.710 --> 02:39.360
the last acknowledgement state.

02:39.380 --> 02:43.880
It waits for a final acknowledgement from the remote host to confirm the termination.

02:45.180 --> 02:46.190
Time wait.

02:46.200 --> 02:52.680
In the time wait state, a host has sent a termination request and is waiting to ensure that the remote

02:52.710 --> 02:55.170
host receives the request.

02:55.200 --> 03:01.350
This state has helps to prevent a premature connection termination due to the delayed packets.

03:02.180 --> 03:04.310
And lastly clause.

03:04.730 --> 03:10.160
The clause state does not represent any active state but indicates a closed connection.

03:10.190 --> 03:16.460
Understanding these TCP states is crucial for network administrators and analysts when troubleshooting

03:16.460 --> 03:21.020
network connectivity issues or analyzing network traffic using tools like Wireshark.

03:22.060 --> 03:28.390
By examining this state transitions and associated packets, they can identify potential problems and

03:28.390 --> 03:31.630
ensure smooth communication between hosts.

03:31.660 --> 03:40.930
TCP reliability sequencing and error recovery mechanisms make it ideal for connection oriented sessions

03:40.930 --> 03:43.660
where data integrity is critical.

03:43.690 --> 03:49.630
However, for applications where speed is paramount and real time communication is more important than

03:49.630 --> 03:55.690
reliability protocols like UDP user datagram protocol may be more suitable.