TCP / IP Animated
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 160 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/33793 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
SoftwareDemonIntelGame theoryConnected spaceFlagIP addressInterprozesskommunikationNetwork topologyComputer animationMeeting/Interview
00:53
AreaSoftwareNetwork topologyGame theoryFeedbackMultiplication signRouter (computing)Local area network
01:45
EncryptionStructural loadPlastikkarteAddress spaceGame theoryGoodness of fitProof theoryInteractive televisionCountingWeb pageEncapsulation (object-oriented programming)Speech synthesisInformationLecture/Conference
02:48
IPPhysical systemCoding theoryVisualization (computer graphics)OracleSystem administratorVertical directionJava appletService (economics)Business IntelligenceDynamic Host Configuration ProtocolInterface (computing)Computer networkServer (computing)Error messageInterprozesskommunikationRight angleMereologyWeightSoftwareWritingInterface (computing)Adventure gameServer (computing)Computer animation
03:42
Dynamic Host Configuration ProtocolComputer networkInterface (computing)Server (computing)InterprozesskommunikationError messageData modelPresentation of a groupRing (mathematics)Token ringLink (knot theory)Bridging (networking)Router (computing)WindowInformationConnected spaceServer (computing)Social classInterprozesskommunikationClosed setSource codeError message
04:38
Presentation of a groupFile Transfer ProtocolUDP <Protokoll>Router (computing)Asynchronous Transfer ModeToken ringRing (mathematics)Bridging (networking)Data modelSoftwareLink (knot theory)Cartesian coordinate systemCommunications protocolTelnetInformationPropagatorProgram flowchart
05:42
Token ringRing (mathematics)Data modelPresentation of a groupFile Transfer ProtocolBridging (networking)Link (knot theory)Router (computing)Computer networkRandom numberSpywareInternetworkingInterprozesskommunikationNumberSequenceHill differential equationTopologyIP addressNetwork topologyMultiplication signSpywareInterprozesskommunikationLocal area networkNumberConnected spaceSequenceCommunications protocolRandomizationPhysical systemProduct (business)Slide ruleDistanceData transmissionDivision (mathematics)
08:15
TopologyRootBitGradientComputer animationLecture/ConferenceMeeting/Interview
09:45
TopologyTelnetServer (computing)Computer networkMessage passingNetwork topologySoftwareHacker (term)Connected spaceAreaProcess (computing)Goodness of fitMessage passingRule of inferenceRouter (computing)Client (computing)Musical ensembleArithmetic meanTelnet
13:36
Server (computing)TelnetComputer networkMessage passingRouter (computing)TelnetConnected spaceServer (computing)Office suiteBitRootMassSource codeCompilerError messageFormal grammarBit rateSpeech synthesisInformationAddress spaceEmailComputer animationLecture/Conference
14:31
Repeating decimalRule of inferenceEmailIn-System-ProgrammierungOperator (mathematics)Hand fanMaxima and minimaGame theoryClient (computing)Source codeMereologyFormal grammarDemosceneClient (computing)Flow separationRandom number generationSynchronizationSlide ruleSoftware testingInterprozesskommunikationInternet forumFlagServer (computing)Computer animationProgram flowchart
15:28
Electronic meeting systemGame theoryClient (computing)MereologyNetwork topologyTwitterSource codeTelnetWritingDependent and independent variablesFlagHacker (term)ResultantProgram flowchartComputer animation
16:29
Game theoryClient (computing)Information managementCommunications protocolInformationSpacetimeRight angleTheoryMultiplication signAreaNumberArithmetic meanComputer animationProgram flowchart
18:21
Game theoryClient (computing)SimulationMessage passingServer (computing)Position operatorSlide ruleClient (computing)WeightLecture/ConferenceProgram flowchart
19:56
Game theoryClient (computing)SimulationServer (computing)TelnetQuicksortSoftwareCASE <Informatik>Connected spaceState of matterGame theoryTelnetDemosceneServer (computing)Source codeClient (computing)MereologyMessage passingMechanism designArithmetic meanFrequencyService (economics)TheoryMultiplication signPoint (geometry)Wave packetSound effectArmWindowTwitterClosed setSet (mathematics)Meeting/InterviewProgram flowchart
24:26
Client (computing)TelnetServer (computing)Data miningGame theorySalem, IllinoisOpen setSimulationSineRight angleTelnetEvent horizonNumberVector spaceSequenceFeedbackEmailIntegerMultiplication signField (computer science)Source codeComputer animation
25:36
Game theoryServer (computing)Client (computing)TelnetNumberSequenceServer (computing)TelnetDependent and independent variablesParameter (computer programming)InformationString (computer science)Order (biology)MetreTerm (mathematics)Slide ruleInsertion lossComputer animation
26:53
Client (computing)Server (computing)TelnetLevel (video gaming)FlagNumberServer (computing)FeedbackClient (computing)DivisorHacker (term)InformationConnected spaceEvent horizonTelnetComputer animationLecture/Conference
28:10
Server (computing)TelnetData miningClient (computing)NumberSequenceServer (computing)InterprozesskommunikationGame theoryCASE <Informatik>Client (computing)Online helpRobot
30:42
Server (computing)TelnetClient (computing)Electronic meeting systemServer (computing)SequenceNumberState of matterAddress spaceConnected spaceExecution unitStreaming mediaDifferent (Kate Ryan album)HypermediaClient (computing)IP addressSynchronizationFluxLecture/ConferenceMeeting/Interview
34:00
Connected spaceVirtual machineKernel (computing)Mechanism designStructural loadBitServer (computing)Semiconductor memoryData managementComputer-assisted translationProxy serverLetterpress printingPatch (Unix)Natural languageBeat (acoustics)Revision controlLecture/Conference
35:15
Data miningTelnetServer (computing)NumberClient (computing)Service (economics)Connected spaceCASE <Informatik>Decision theoryRootMechanism designServer (computing)Right angleSPARCMereologyRouter (computing)Stress (mechanics)Electric generatorFlag
37:48
Server (computing)TelnetData miningServer (computing)Web 2.0CASE <Informatik>Firewall (computing)Network topologyPhysical systemIP addressDifferent (Kate Ryan album)Connected spaceFlagMereologyInformationWeightSystem callDiscounts and allowancesMeeting/Interview
40:47
Client (computing)TelnetServer (computing)Data miningComputer networkSoftwareNetwork topologyClient (computing)Firewall (computing)MereologyDependent and independent variablesServer (computing)InterprozesskommunikationConnected spaceInheritance (object-oriented programming)Drop (liquid)Physical systemSource codeVirtual machineLecture/ConferenceComputer animation
42:36
Client (computing)Server (computing)MereologyMatching (graph theory)NumberRandomizationString (computer science)SynchronizationSource codeDrop (liquid)Right angleDependent and independent variablesFlagStreaming mediaExistenceLecture/ConferenceMeeting/Interview
43:48
TelnetServer (computing)RootResolvent formalismRouter (computing)Interface (computing)DampingError messageSource codeRoutingAddress spaceServer (computing)
45:14
Host Identity ProtocolServer (computing)TelnetClient (computing)Computer networkGame theorySystems engineeringSimulationTable (information)Error messageInterface (computing)RootFreezingWordTelnetCommunications protocolServer (computing)Client (computing)Router (computing)SoftwareInformationDampingWindowGroup actionLevel (video gaming)Connected spaceWeb pageWeightRule of inferenceLink (knot theory)KinematicsDifferent (Kate Ryan album)Lecture/Conference
48:28
Computer networkRight angleRoutingSoftwareRouter (computing)RootLecture/ConferenceComputer animationMeeting/Interview
49:26
Computer networkCorrelation and dependenceClient (computing)Game theoryServer (computing)Information managementOpen setSimulationServer (computing)SoftwareDifferent (Kate Ryan album)Point (geometry)Computer animationMeeting/Interview
50:41
SimulationServer (computing)Game theoryClient (computing)Open setMaxima and minimaSoftwareField (computer science)Level (video gaming)Server (computing)Table (information)Client (computing)MappingRoutingConnected spaceRouter (computing)Boom (sailing)Address spaceReading (process)DemosceneMereologyComputer animation
53:13
Client (computing)Server (computing)Game theoryDataflowMatching (graph theory)SoftwareProjective planeServer (computing)Firewall (computing)Connected spaceRoutingCommunications protocolHacker (term)Different (Kate Ryan album)Game theoryRootSimilarity (geometry)Meeting/InterviewProgram flowchart
54:56
Normal (geometry)Information managementMilitary operationSimulationElectronic meeting systemGame theoryMetropolitan area networkBuffer solutionAlgorithmClient (computing)Connected spaceCASE <Informatik>MiniDiscMultiplication signMessage passingDependent and independent variablesModal logicFlagSound effectPower (physics)Error messageWeightSheaf (mathematics)Server (computing)Rule of inferenceLine (geometry)PlanningState of matterService (economics)Closed setHacker (term)RootDirection (geometry)BitOpen setComputer animationProgram flowchart
01:00:03
SimulationClient (computing)MereologyMultiplication signCASE <Informatik>Data transmissionServer (computing)Pattern languageMeeting/InterviewComputer animationProgram flowchart
01:01:31
SimulationNormal (geometry)Maxima and minimaMultiplication signConnected spaceNetwork socketClient (computing)QuicksortEntropie <Informationstheorie>CASE <Informatik>Source codeMereologyPattern languageResultantServer (computing)Arithmetic progressionProxy serverWeightArithmetic meanComputer animationMeeting/InterviewProgram flowchart
01:02:48
Information managementSimulationMaxima and minimaProxy serverServer (computing)Process (computing)Service (economics)Address spaceSoftwareConnected spaceWeightMultiplication signFirewall (computing)Software testingConfiguration spaceMechanism designNetwork socketLocal ringLastteilungStress (mechanics)Integrated development environmentSocket-SchnittstelleComputer animationProgram flowchart
01:04:24
Formal grammarElectronic meeting systemRegular graphIntegrated development environmentPoint (geometry)TunisTheoryMultiplication signComputer animation
Transcript: English(auto-generated)
00:05
Hello, everybody, welcome to Europe-ython. We are going to attend a wonderful interactive session, and it is a game with pen and paper, showing a basic communication with TCP.
00:23
So we will see how a connection is established and how is it closed. Everything is interactive, so you're gonna write down IP addresses and checking TCP flags on small flyers.
00:49
You should form three or four people teams, and every three or four people is a small local area
01:04
network connected to a hub switch or router. The talk is presented by Danilo Bashano. He's a first-time speaker,
01:20
so I hope to welcome him warmly. And it is the first time that he makes this TCP IP game, so your feedback to make it grow and to make it better is really appreciated, so next year we could do
01:42
even more and more complex stuff, like load balancing, encapsulation, and so on. Encryption. Encryption. Last year, we made a game with Mac addresses
02:01
and basic getaways, and people enjoyed a lot, and somebody came asking if I was delivering a package with all the cards of the games, but, well, let's start now.
02:21
Danilo speaking, I will try to help him when needed. Good luck, Danilo. Thank you, Roberto, Pauli. So this is a TCP IP animated interactive session.
02:43
You can touch the packet that will transmit on the network and write on paper
03:02
and simulate how this packet travel on the net. I am Danilo Bashano, and I work in a company, Partang, that sponsored this talk.
03:22
And Roberto Pauli helped me to this adventure. So, we started to bring up network interfaces
03:41
with the DHP server, and this is the DHP server. First, we make the handshake. We see just the layer TCP and the IP.
04:02
Communicate some data. We introduce some communication error to, this is what we will see. And then, at last, say goodbye with closing connection.
04:24
This is just an overview of his source stack. It's divided by layer, and each layer are encapsulating information, one inside the next layer.
04:44
So, from Watson, it's the physical, it's how the PC are connected. So, the wired, or something else, data link, network and transport.
05:03
We will focus our attention in network layer with the protocol IP and transport layer with the TCP. Then, up of this layer, we have the application layer,
05:22
and for not introducing some information, some problematics, but other protocol, we choose the Telnet application. It's the simplest application.
05:42
We'll set the just to transmit byte. So, I leave Roberto Pauli, introduce him. Now, I start to give the... Danilo makes the DHCP server, providing your IP addresses and pants.
06:02
Please remember, you should form teams of four people. Every four people, it's a local area network. So, check your teammates and form your teams. What's essentially TCPP is...
06:24
TCPP provides the ability to have a reliable protocol. It introduce the connection concept. That means that me and you knows, before starting transmitting data, who we are.
06:45
This is something that is not provided by other protocols. So, with these writing packets, with pen and paper, we will understand why all those passages are important.
07:07
So, for every transmission, it happens, something that we see in war movies, like, okay, Roger Death, and then the other says, okay, Roger Death.
07:24
TCPP IP is something like radio communication during war movies between the surgeons and the chieftain. What we see is that after that,
07:41
TCPP IP provides a basic hijacking protection using random initial sequence number. That's something that we will see if we have time while we wrote packets. And that all these checks, all those in knowledge,
08:01
enables retransmissions. So, Danilo is providing you pens and paper. This is our basic topology. So, one of your team should be the router,
08:23
the one that enables other people to communicate. Please choose something that knows a bit of TCPP IP, but it's not compulsory. And then, okay, now I'm going to help you.
08:45
In making the teams. So, is there some team already made? Please raise your hand. Team one, who is team one? Okay, all your hands, team one, raise all your hands.
09:01
Please give you a name. Be doing yourself, chose a name. The same for the other teams. So, this is team two. Raise your hand, team two, okay?
09:23
Team two, just team two, would you? Okay, team two, wow. We are team Rimini. Team Rimini, great. Show me this team, I love you.
09:51
Big names. Bologna team. Bologna, okay, just like Spaghetti a la Bolognese.
10:07
Wonderful. Name router switch. Router switch, wow, great.
10:23
Just watching, okay, wonderful. No problem, you can join whenever you want. It's just something like plugging another device in. Okay, another standby device.
10:53
Excuse me?
11:03
Yeah, but you can't have a router if you're not a switch. Yeah, for this setup, as they just have an IP, they must be connected to something that is L2 enabled.
11:23
So, we couldn't have root, just router. Okay, as the packets are, well, not many,
11:45
you can reuse them. Maybe for the first connection, you can use just one piece of paper and then move on, Benilo, it's up to you.
12:01
Okay, we just created some subnets in the topology like this, so we just are, one people is the router switch, it's the blue one,
12:24
and all the other people in the subnet are connected to the switch. The router have the happy ends with the two, five, four, and in every subnet, there are the dot one,
12:44
and he's the telnet server, and are listening on port 23. All others are the user, all right.
13:01
Okay, first goal is to make an handshake. Handshake is used to establish a TCP IP connection over an IP network. It's also called the three-way handshake because it's needed to transmit three messages.
13:21
First one is SYN, the second one is from router to client, and it's called SYN hack, and the last one, hack. The name of the packet are the same name of Flex,
13:44
so we will explain later. The goal is a whole user will establish a connection to the telnet server, every packet must go firstly
14:05
to the router switch, then to the server. This is just a datagram of IP header. The information that we use in this speech
14:22
is the source address and the destination addresses. So you have to compile the packet with the source and destination. The other part of packet is the TCP datagram,
14:41
and we have to use 23 as the destination port. With source ports, you can write a random number, and we use also TCP Flex and data for transmit data.
15:06
In this slide, you can see the handshake communication between the client and server. Client sends the first packet when the flag SYN is checked.
15:23
SYN is for synchronization. I mean, I want to start a synchronization with you. So you can start to write source IP, destination IP, SYN flag, and 23 as the destination port.
15:48
To the telnet server, then the telnet server, the people that have the IP with one
16:01
have to respond with another packet with the SYN and hack flagged.
16:24
Okay, ready, set, go.
16:42
In the first packet, there is no hack, it's empty. I mean, it's not zero, it's zero bytes.
17:11
So it's zero? Yeah, but it's. It's not zero bytes because it's fixed? It's zero, yeah. So it's zero?
17:20
Yeah, it's not red on the protocol. Yeah, but the space is there? Yeah. Nothing, because it's the first one. All right, let's try. To the router? So I'm a router, I don't have any information
17:40
about the network, so I can't do anything. Okay, okay, but as we are in TCP, we think that, well, we simulate that you already have, I mean, we skipped the ERP. So I assume I've got a MAC table? Yeah, you do whatever is L2 in background.
18:05
You don't show them. Yes, okay, first exchange, done.
18:20
Okay, so you sent a scene, but you shouldn't have provided any data, because, okay, because it's the handshake. You don't know if it's him. You didn't already start at something, so you can't rely that the message
18:42
have been routed to the ERP destination. You might not even know that he exists. Okay, so what, just reuse blankets?
19:04
No, he should know. You're the server. So it's you that should send him. He has to wait, you are the server, you just received this, or you wrote it?
19:25
No, you should wait for packets to come to you. Okay, the telnet, well, it was in the previous slide. Actually, the client, the server is always the dot one.
19:42
Yes, whatever you got, dot one. Okay, yeah, the router get it, and he makes all the ERP stuff, and provides, okay, you are just, yeah?
20:09
In this case, you don't need to, you are on the same local network, you don't have next to. Because it's always on the same subnet.
20:23
You should, okay. Ah, you have a hate, ah, okay. Okay, okay, now you should have, it's, excuse me, you just put. Two eight, Alice fine now.
20:42
You should have had only one network, because the second part of the game is connecting the two routers, so you exchange packet with him? No, exactly, until you meet with him.
21:05
Okay, perfect, wonderful. So, okay, you, just the same? No, well, the port is 23. Yeah, because telnet is 23.
21:22
Okay, and you, so when you receive this packet, what happens, you should acknowledge, you set an ACK on that, perfect, and send them back.
21:40
You actually should write ACK as the source IP, but we have a very few packets. So we save it for this time, okay? Exactly, just use last octet.
22:10
Okay, that's it. Here, everything fine? Did you establish the connection?
22:23
Okay, you didn't have any, oh, very good. Can I see the first one? This was the scene. Another important.
22:43
I have a scenic messenger. Another important thing is the, as you showed, the client state and server state. Server starts with the closed door,
23:03
then where the telnet server comes up, the server are listening on the port 23. The client connection state firstly are closed.
23:21
Send the scene packet and become sent, and the server scene received. After end shake, when the end shake are completed,
23:40
the old client and server, both are in the established connection state. All right, we can go on.
24:07
So now the connection, now the connection is established and we can start to talk.
24:23
The message, the data messaging is my name is, and write your name. Send the packet with, yes, okay. Send the packet to the telnet server,
24:43
then receive the packet and come back a feedback with a package with the hack flag. So now I want to introduce another two fields.
25:01
The sequence number, acknowledge number. So the sequence number is just an integer when the start from zero and increment plus one
25:22
every time someone send a packet. Acknowledge number is another field in the TCP header to check if the packet are received well
25:45
or if there happened something wrong like lost data or packet loss. Sequence number is also used to,
26:00
if I receive the packet, not in order. So it's used to sort my response. In this slide, you can see the end shake, the end shake with the other two parameters set.
26:29
Now we have to send this information to the server telnet. The information is my name is Danilo
26:41
and start with the sequence number zero. The server telnet receive zero to 16 byte because the string my name is Danilo are 17 bytes.
27:04
Then the server receive a feedback to the client with the flag hack and the number of byte received, right? So this is possible to send information
27:31
only after the TCP IP connection is submitted.
27:53
At the end, the server telnet can know all your names.
28:12
Is it everything clear? For now, we are going to start with zero clearly for the game, but what happens is the first
28:24
sequence number is a random one because it helps to avoid other people introducing themselves in the communication and the first value of sequence of bot hosts are used just like a secret
28:44
between the client and the server. And well, we can start writing our first data packet containing my name is providing, try to provide a sequence and a knowledge number
29:02
in your communication. If you are not able, it's no problem. Just try to do it.
29:23
Someone needs some help.
33:07
So which is the packet that you received? Okay. So that's okay. Those are two different strings, two different connections. One from number one and two.
33:24
The other one is from number three and one. Every connection has its own stream and has its own flux of sequence and the knowledge.
33:41
Questions? So a question for all those Linux guys. Where are all those synchronization and a knowledge bytes, all those IP addresses stored in clients and servers?
34:03
Yeah, all those TCP data stored in the servers, in memory, exactly. So remember if your servers have to manage
34:23
thousands of connection, that you need to use enough RAM for TCP. If you set up a load balancer, a virtual machine that is a load balancer,
34:40
just don't think about how much Apache's RAM or NGINX RAM or HAProxy's RAM is going to consume. But think and check how many concurrent connection you are going to manage. Okay, because every connection is going to use memory.
35:06
Now in the latest Linux version, they have reduced a bit the footprint. But if you're interested in, there is some kernel mechanism that is named
35:24
TCP floating prevention. Have a look at it, it's interesting. Okay, because some years ago, they thought that it could be removed. But after some stress testing,
35:40
somebody said, okay, even if we have removed, lowered the TCP footprint on our Linux servers, still we have benefit in having a seen-flood prevention. Packets floating, okay, hey?
36:12
No, there is no seen flag there. Only a knowledge.
36:21
So if someone tried to send a packet to the server, but for example, wrong the port number or the server died, what's happened?
36:45
The first packet is sent to the router. The router can know the IP, the destination IP, and give the packet to the server.
37:00
Then the server receive the packet, but no one services are in listed. Listening on that port, and in this case, the server generate reset the packet back to the client.
37:27
And the client, this is the case of connection refused. Right? Okay. Roberto?
37:40
Okay, try to implement this case. So a client sends a packet to the server on port 80, but the server has no web server listening, so he doesn't know what to do with that packet.
38:08
This case also happened when, for example, firewall closed the incoming request to the some port.
38:27
Now the server replies, flagging the reset flag. No, not that way. The wrong part. Yeah. The server will not always discard the packet,
38:44
but wow, you can see an RST flag, and replies back.
39:01
When server replies with a reset packet, you still have information. The information you got is that the server exists.
39:21
Okay? And it is very useful to send packets to non-listening ports if you want to discover a network topology. Okay, so you don't know which IP addresses are there around, so you start trying to connect different port
39:44
and wait for reset packets to come back. Then you know those hosts are alive, and maybe if there is no port, no 80 ports, there is some other ports that is listening.
40:04
No, well, ping is something different. When you ping a host, you may have that host that don't accept, or don't reply to ping requests.
40:22
But if you have a system that lives on a host that doesn't allow ping requests, okay, so it's firewall in some way, that host might still reply to connection attempt
40:43
on different hosts, on different ports, okay? So maybe you have a firewall that disables ping requests and responses, but they don't just block all ports around. So if your network is firewall for ping, you can try to probe to other ports
41:02
and discover networking topologies. This is what trace root, that is another client program, does. It does it with UDP and with TCP. Usually with TCP, it's more probable
41:20
that you get insights of a network, because with UDP, maybe you have still firewalling. It's not easy to have TCP firewalling on all ports, because there are machine listening. So maybe some system for guests to firewall everything.
42:06
Because it's the part that is not listening. Everybody recites, okay? Remember that all these recites, when a client receive a reset with a source port,
42:24
what happens, it drops the connection, okay? So if I am exchanging communication with a server on port 80, and they receive a reset, sourcing port 80, I drop all the rest of the data.
42:46
So. Yes, yeah, but the server exists. So it's the server that responds to the client. I can even forge packets and send them to clients
43:00
with my 80 ports so that all clients just start dropping packets from a legitimate server. This is how using a random synchronization number helps, because a client accepts a reset packet
43:22
only if the synchronization and a knowledge plug match the one of the stream they are communicating on. So if I receive a reset from a server, but the reset, but the knowledge and synchronization
43:41
flag doesn't match, I just skip this reset as a forged packet, okay? Good question. Yes. If the destination is reachable,
44:02
so when you try to talk to another server, the router receive the packet, but the router don't know where send your packet, and the router give you back an hippie packet,
44:26
not TCP IP, just the hippie with the error. Now with the error, no root to host. Okay, remember, if you're looking for those ICMP packets,
44:43
then it's about no root to host and so on. If you are on your own laptop, and your laptop, your PC, doesn't resolve this address, it's your local interface replying back
45:01
with this no root to host. So if you use TCP DAMP trying to get those kind of packets, probably the best way to track them is to TCP DAMP listening on all interfaces, not just on the outgoing interface.
45:23
So if you want to have a best insights of traffic and ICMP packets, ICMP, it's out of scope for this talk. We actually should have something about the no root to host stuff,
45:41
but we don't want it to go on the ICMP stuff. You have a lot of kind of errors, and there is a table where you should check and map each kind of errors on what could have happened on the network.
46:01
So check out the map page, if you man ICMP, probably you can just get all those information. Try to TCP DAMP stuff to get. There is a very nice book that is TCP IP illustrated
46:23
where you can get a lot of examples. There are two releases. The first one, which I prefer, is very simple, very straight, and is very useful for learning all those stuff. And there is a second release that is more verbose,
46:43
and it is used, that is better than a Windows client. I don't like it very much, but it is very comprehensive, and it can be very useful if you have many protocols to check as a reference.
47:00
So let's move on with the... So and more complicated scenario with now we have all the router linked together, and now the subnet can talk,
47:23
one to each other, and the goal of this scenario is that our client in a subnet have to establish a connection to a telnet server in another subnet.
47:49
So you can speak about two clues, subnet group.
48:17
So let's connect the routers.
48:28
So you are the routers. Now you should populate this one. We spoke with him. Yeah, you should exchange with the next stop.
48:41
You can write off his name, maybe. So your L2 layer is the name of the other router, the Christian name of the other router, okay? So the router from your network.
49:03
Okay, maybe here we can have a three-way routing stuff. So one connected with two, and two connected with three. So it would be, yeah, dispatching for two routes.
49:27
And shake, okay, and shake. Start and shake now. So start and shake with the server on a different network, a different subnet. Okay, it's both two and three write to the server.
49:46
For example, on a different network.
50:38
I mean that they speak on a different network.
50:43
Not always the same layer, but they speak, for example, on a private routing network. Yeah, so it happens at the IP level. TCP is only between client and server. Router just see IP, unless they do something like
51:05
mapping and manipulating layers. There is always a C, not C-NUC.
51:30
Okay, that's going here. It's always the same, the server is always the dot one.
51:48
So, yeah.
52:01
Okay, this routing can happen on the same networks, okay? Or there can be a separate network where you route packets that is not the one which the clients are connected on. For example, there can be a 10, a 198 network.
52:24
So you and him speak on 198. And he has a routing table where the 10 dot one goes through your address on that network and you know where to deliver. And so there can be a routing network
52:42
where all the routers speak between themselves on those 108, okay? Or, well, there can be multiple hops. Boom.
53:04
Okay, if the connection is low, okay? You can start to understand how important it is to start problem network.
53:21
And if the connection is low, try to send packets to other hosts and try to get a reset to check if the problem is the server or the routing. If the packet from, if the reset packet comes back,
53:41
then probably there is a firewall on that host. Otherwise, that host would have replied with a reset or with a knowledge, okay? Try to understand. Try to mangle to track your human network.
54:04
Next year, we'll do it with 100 people and check what happens. Yeah, with the L2 game, people just start not complying
54:23
with the protocol to win the game. We made a competition for the team that was going to exchange the packet faster and they start to get just like, this is Frank, this is John, and they just go straight on.
54:42
Yeah, exactly. And then we examined all the kind of hacks they do to win and try to make similarities with the difference between hubs, router, and so on. So we found that somebody just dropped the hubs
55:03
to be smart and remember that ports are one-to-one, other reuse packets. And we hope that after this experiment this year, we can fine-tune the game to have something like that.
55:20
Next year, we wanted to do just like, Nagel algorithm and caching, buffering, and so on. But the problem is we need some refinement and if people get the first impact with TCP, it's very hard to introduce
55:40
further concepts on this kind of game. Yeah, I don't know if we have this case. We had a case with no root two hosts on that part.
56:08
Yeah, it triggered the retransmission. Okay. Yeah.
56:26
Well, probably if somebody wants to try this next year, we could plan for two sessions, two different sessions, one with TCP basic and the other one with TCP complex
56:42
but with the same teams. We can do this with exchanging people between teams. It would be very complex, I think. So now I'll leave your connection open. It's time to close it. And this is the rule
57:02
to close an established connection. It's made by four packets. The first is Fin, the flag Fin. The server responds with the hack. And then another Fin and hack,
57:21
because the connection we had is a bit directional. So we have to do two closing, one from client to server and another one from server to client.
57:42
It's possible to collapse the second and third messages in just one with both flag hack and Fin. So this modality, you can close the connection
58:02
with the three packet exchange, exchanging three packets. I want to show you the client state and server state also, starting from established connection and passing from close weight and time weight
58:32
and then close, because after closing, the client could be receive
58:44
another data messages under the closing connection. So maintain the weighting for a time, this delayed messages.
59:03
And sometimes on server, we have a lot of connection in a close weight state. This is happen when the closing,
59:21
when the closing connection are not completed. So if you want to try to close your connection, you just send Fin, receive hack.
59:47
Yes, essentially Fin means I'm not going.
01:00:01
to send you any more packets Fin doesn't mean I'm not going to read more packet Okay so To send the fin just means I can receive more packets from you
01:00:22
Okay But I won't send any more This is the reason why we need two packets A fin that is I'm not going to send any more And then A knowledge that the other one
01:00:41
Is done with sending Okay this last part the infamous time wait stuff is very important because As you can see
01:01:01
this team had a quite long routing layer Okay, they had two steps between clients and server and in that case packet transmission was slow
01:01:20
in this case this time wait enables to get Delayed packets to reach the client in this case Without that this connection this socket to be reused by another one
01:01:41
imagine that We reuse we don't have time wait The connection is closed I reuse the socket so reuse the coupling of source the destination part This destination part received our delayed packet
01:02:02
And what does it do with the packet that he doesn't know what to do He sends back a result He says you are not a connection established to me So you should close so a new client sends a legitimate
01:02:21
Connection request for example and gets back a result. He thinks that the server is not responsive instead It should be Or differently so this is important to have a time weight Okay Time weight could be problematic because means that there is a socket in use on the server
01:02:45
And if you have a server with both a proxying layer Okay between another process that is local Okay So for example, I have an HA proxy on the same server then the bucket service
01:03:07
When connection starts to get closed I have a local connection in time weight Okay or if I have firewalls or
01:03:21
a load balancer so you can there are mechanism for socket reuse when You think that you can have a lower time on Time weight. Okay, you should do it only if
01:03:45
You trust that your network has a low latency So you won't get packets very fast very with with a big delay Okay, so if you trust your network is very fast so you don't have latency
01:04:01
You can reuse sockets for example locally and so on Otherwise if you have time weight just uh stick with it Don't just make or use magic in into your tcp configuration because it's it probably getting things were
01:04:21
Words then you you get it always test stress test your tcp environment Before tuning don't tune tcp on theoretical stuff Because it's not going to work at a certain point Just do if you prove it that it's better for you
01:04:43
Okay. Thank you, roberto And thank you to have you for attention And so fin I would thank you very much. Danilo because at first in
01:05:08
This talk should have been brought to you by another colleague that had an issue and bravely danilo
01:05:21
Took it over Made it up Without starting it first and tried to make it to make it in a very brief time to Have it delivered to you. So thank you danilo and hope to see you next year
01:05:40
At europython, thanks to you polly