MySQL master-slave and master-master replication. Step by step configuration instructions.

One may say that there are a lot of MySQL replication manuals, but latest versions of MySQL server have changed the way how configuration should be applied. Most of the manuals do not reflect these changes. I want to describe some other aspects of configurations also. As far as there are a lot of good manuals about replication, I think there is no need to dove into details what is the replication. Just want to mention that this technique is usually used for load balancing on database servers. If you have a lot of read requests (most common for web applications) master-slave replication should suit your needs well. In this case you will do write transactions on master host and read requests on slave hosts, because data is populated from master to slave much faster than from slaves to master and to other slaves.

But sometimes you might have more write requests or may have other (application related) reasons to start another type of replication. You can see it on the next fugure and that is so called  master-master replication.

In this article I will describe simple master-slave architecture with 2 hosts and simple master-master replication with the same 2 hosts. Our final goal is to configure master-master replication, what includes several sub-steps, so lets  start. Sure you should configure network services on both systems. For example:

Master 1/Slave 2 ip: 192.168.16.4
Master 2/Slave 1 ip : 192.168.16.5

Iptables rules for MySQL replication

It will be good practice to allow connections only from other nodes envolved into the replication and deny from other. By the way this will work good for some other services that are allowed to communicate nly with the known hosts. You can define port range like 1025:3306 (I am going to write more about iptables soon, so follow my blog ontwitter).

  1. iptables -A INPUT -p tcp -s 192.168.16.4 –sport 3306 -d 192.168.16.5 –dport 3306 -m state –state NEW,ESTABLISHED -j ACCEPT
  2. iptables -A OUTPUT -p tcp -s 192.168.16.5 –sport 3306 -d 192.168.16.4 –dport 3306 -m state –state ESTABLISHED -j ACCEPT

MySQL master-slave replication

Basically master-master replication consists of two master-slave replications. Now we will configure master-slave replication from the first server to the second one.

Create relication user on Master 1:

  1. mysql> grant replication slave on *.* to ‘replication’@192.168.16.5 identified by ‘slave’;

And start master:

  1. mysql> start master;

Master 1 changes to /etc/my.cnf:

  1. [mysqld]
  2. datadir=/var/lib/mysql
  3. socket=/var/lib/mysql/mysql.sock
  4. old_passwords=1
  5. log-bin
  6. binlog-do-db=<database name>  # input the database which should be replicated
  7. binlog-ignore-db=mysql            # input the database that should be ignored for replication
  8. binlog-ignore-db=test
  9. server-id=1
  10. [mysql.server]
  11. user=mysql
  12. basedir=/var/lib
  13. [mysqld_safe]
  14. err-log=/var/log/mysqld.log
  15. pid-file=/var/run/mysqld/mysqld.pid

Slave 1 changes to /etc/my.cnf:

  1. [mysqld]
  2. datadir=/var/lib/mysql
  3. socket=/var/lib/mysql/mysql.sock
  4. old_passwords=1
  5. server-id=2
  6. [mysql.server]
  7. user=mysql
  8. basedir=/var/lib
  9. [mysqld_safe]
  10. err-log=/var/log/mysqld.log
  11. pid-file=/var/run/mysqld/mysqld.pid

Important! Pay attention that you should not configure master-host, master-user, master-password, master-port via my.cnf on slave server now.

On Master 1:

  1. mysql> show master status;
  2. +————————+———-+————–+——————+
  3. | File                   | Position | Binlog_Do_DB | Binlog_Ignore_DB |
  4. +————————+———-+————–+——————+
  5. |mysqld-bin.000012 |      106 | adam         |                  |
  6. +————————+———-+————–+——————+
  7. 1 row in set (0.00 sec)

On Slave 1:

  1. mysql> CHANGE MASTER TO MASTER_HOST=’192.168.16.4′, MASTER_USER=’replication’, MASTER_PASSWORD=’password’, MASTER_PORT=3306,MASTER_LOG_FILE=’mysqld-bin.000012′, MASTER_LOG_POS=106, MASTER_CONNECT_RETRY=10;

Attention! This will configure slave and server will remember settings, so this replaces my.cnf settings in latest versions of MySQL server.

Start slave on Slave 1:

  1. mysql> start slave;
  2. mysql> show slave statusG;
  3. *************************** 1. row ***************************
  4.                Slave_IO_State: Waiting for master to send event
  5.                   Master_Host: 192.168.16.5
  6.                   Master_User: slave
  7.                   Master_Port: 3306
  8.                 Connect_Retry: 10
  9.               Master_Log_File: mysqld-bin.000012
  10.           Read_Master_Log_Pos: 1368129
  11.                Relay_Log_File: mysqld-relay-bin.000005
  12.                 Relay_Log_Pos: 605530
  13.         Relay_Master_Log_File: mysqld-bin.000012
  14.              Slave_IO_Running: Yes
  15.             Slave_SQL_Running: Yes
  16.               Replicate_Do_DB:
  17.           Replicate_Ignore_DB:
  18.            Replicate_Do_Table:
  19.        Replicate_Ignore_Table:
  20.       Replicate_Wild_Do_Table:
  21.   Replicate_Wild_Ignore_Table:
  22.                    Last_Errno: 0
  23.                    Last_Error:
  24.                  Skip_Counter: 0
  25.           Exec_Master_Log_Pos: 1368129
  26.               Relay_Log_Space: 1367083
  27.               Until_Condition: None
  28.                Until_Log_File:
  29.                 Until_Log_Pos: 0
  30.            Master_SSL_Allowed: No
  31.            Master_SSL_CA_File:
  32.            Master_SSL_CA_Path:
  33.               Master_SSL_Cert:
  34.             Master_SSL_Cipher:
  35.                Master_SSL_Key:
  36.         Seconds_Behind_Master: 0
  37. Master_SSL_Verify_Server_Cert: No
  38.                 Last_IO_Errno: 0
  39.                 Last_IO_Error:
  40.                Last_SQL_Errno: 0
  41.                Last_SQL_Error:
  42.   Replicate_Ignore_Server_Ids:
  43.              Master_Server_Id: 1
  44. 1 row in set (0.02 sec)

Above highlighted rows must be indicate related log files and  Slave_IO_Running and   Slave_SQL_Running: must be to YES.

MySQL master-master replication

Master-master replication is actually two master-slave replications. This allows to make read and write transactions on both servers, as data propagation from master to slave goes very fast oposit to data propagation from slave to master which requires much more time. So, to create master-master replication we should now configure Master 2 – Slave 2 replication.

Create a replication slave account on Master 2 for Master 1/Slave 2:

  1. mysql> grant replication slave on *.* to ‘replication’@192.168.16.4 identified by ‘slave’;

And start master:

  1. mysql> start master;

Master 2 changes to /etc/my.cnf:

  1. [mysqld]
  2. datadir=/var/lib/mysql
  3. socket=/var/lib/mysql/mysql.sock
  4. old_passwords=1
  5. log-bin
  6. binlog-do-db=<database name>  # input the database which should be replicated
  7. binlog-ignore-db=mysql            # input the database that should be ignored for replication
  8. binlog-ignore-db=test
  9. server-id=2
  10. [mysql.server]
  11. user=mysql
  12. basedir=/var/lib
  13. [mysqld_safe]
  14. err-log=/var/log/mysqld.log
  15. pid-file=/var/run/mysqld/mysqld.pid

Slave 2 / Master 1 changes to /etc/my.cnf:

  1. [mysqld]
  2. datadir=/var/lib/mysql
  3. socket=/var/lib/mysql/mysql.sock
  4. old_passwords=1
  5. log-bin
  6. binlog-do-db=<database name>  # input the database which should be replicated
  7. binlog-ignore-db=mysql            # input the database that should be ignored for replication
  8. binlog-ignore-db=test
  9. server-id=1
  10. [mysql.server]
  11. user=mysql
  12. basedir=/var/lib
  13. [mysqld_safe]
  14. err-log=/var/log/mysqld.log
  15. pid-file=/var/run/mysqld/mysqld.pid

Important! And again you should not configure master-host, master-user, master-password, master-port via my.cnf on slave server now.

On Master 2:

  1. mysql> show master status;
  2. +————————+———-+————–+——————+
  3. | File                  | Position | Binlog_Do_DB | Binlog_Ignore_DB |
  4. +————————+———-+————–+——————+
  5. |mysqld-bin.000012 |      106    | adam            |                  |
  6. +————————+———-+————–+——————+
  7. 1 row in set (0.00 sec)

On Slave 2:

  1. mysql> CHANGE MASTER TO MASTER_HOST=’192.168.16.5′, MASTER_USER=’replication’, MASTER_PASSWORD=’password’, MASTER_PORT=3306,MASTER_LOG_FILE=’mysqld-bin.000012′, MASTER_LOG_POS=106, MASTER_CONNECT_RETRY=10;

Attention! As I have already mentioned in the previous section this will configure slave and server will remember settings, so this replaces my.cnf settings in latest versions of MySQL server.

MySQL master-master replication and autoincrement indexes

If you are using master-slave replication, than most likely you will design your application the way to write to master and read from slave or several slaves. But when you are using master-master replication you are going to read and write to any of master servers. So, in this case the problem with autoincremental indexes will raise. When both servers will have to add a record (different one each server simultaneously) to the same table. Each one will assign them the same index and will try to replicate to the salve, this will create a collision. Simple trick will allow to avoid such collisions on MySQL server.

On the Master 1/Slave 2 add to /etc/my.cnf:

  1. auto_increment_increment= 2
  2. auto_increment_offset   = 1

On the Master 2/Slave 1 add to /etc/my.cnf:

  1. auto_increment_increment= 2
  2. auto_increment_offset   = 2

SMTP-Gated

What is SMTP-Gated ?

It is a server which have the ability to Scan, Recognize, and  Block Mails that Containing Spam or Viruses.

How it works ?

It acts like proxy, intercepting outgoing SMTP connections and scanning session data on-the-fly. When messages is infected, the SMTP session is terminated.

Features:

  1. Transparency – is meant to be totally transparent for users, but stone-build for worms 😉
  2. Message data is intercepted on-the-fly, and scanned just before acknowledged to SMTP server
  3. Does not break AUTH, PIPELINING or STARTTLS (TLS without scanning)
  4. Can block messages if AUTH is not used (optionally passing if AUTH is not supported by MSA)
  5. Can insert source IP (pre-NAT) and ident* into message header
  6. Can block any mail from infected hosts for defined time
  7. Logging of MAIL FROM and RCPT TO (plain or as base64-ed MD5)
  8. Logging of HELO/EHLO hostname
  9. Can impose some limits on number of SMTP sessions: total, per IP, per ident*
  10. Can reject connections when load exceeds some limit
  11. Can skip spam-scanning if load is high
  12. Executing user script on certain events
  13. Scanning limited to messages up to configured size
  14. Can be used to build scanning-farm for one or more routers*
  15. Logs all connections via syslog
  16. Has nifty status screen 😉
  17. Message size limit (since 1.4.16-rc1)
  18. Outgoing XCLIENT support (since 1.4.16-rc1)
  19. Conditional content scanning depending on SMTP-AUTH status (since 1.4.16-rc1)
  20. Regular expression (regex) conditions for HELO/MAIL FROM/RCPT TO (since 1.4.16-rc1)
  21. SPF checking (since 1.4.16-rc1)

Supports:

  1. Content scanning:
    1. Clam AntiVirus daemon (clamd)
    2. mksd – daemonised version of mks_vir
    3. SpamAssassin antispam scanning
  2. Access checking:
    1. libpcre for HELO/MAIL FROM/RCPT TO regular expressions (not-)match
    2. libspf2 for SPF (tested with debian libspf2 1.2.1)
  3. Uses various NAT frameworks (for standalone mode), or ident/proxy-helper* for external mode
    1. patched ident daemon
    2. proxy-helper daemon
    3. netfilter framework of Linux
    4. ipfw on FreeBSD
    5. BSD/pf (packetfilter)
    6. BSD/ipfilter

IP-Tables Concepts

I will try -As much as I can- to explain IP-Tables Concepts in a simple way.

What is IP-Tables ?

(My Definition) The IP-Tables is a peace of software to filter the network transition (Packets).

(Wikipedia’s Definition) iptables is a user space application program that allows a system administrator to configure the tables provided by the Linux kernel firewall (implemented as different Netfilter modules) and the chains and rules it stores.

 The Contents of IP-Tables:

  1. Tables
    • The Table is: A set of chains which designed to do a specific function
  2. Chains
    • The Chain is: A set of rules that are applied on packets that traverses the chain.
    • Every Chain have a specified purpose which you will know while we are talking.
  3. Rules
    • A rule is a set of a condition or several conditions together with a single action.
    • the action of a rule will be applied if all the conditions of that rule have been achieved.

What is NAT – Network Address Translation ?

NAT allows a host or several hosts to share the same IP address in a way.

HOW ?

let’s say we have a local network consisting of 5-10 clients. We set their default gateways to point through the NAT server. Normally the packet would simply be forwarded by the gateway machine, but in the case of an NAT server it is a little bit different.

NAT servers translates the source and destination addresses of packets as we already said to different addresses. The NAT server receives the packet, rewrites the source and/or destination address and then recalculates the checksum of the packet. One of the most common usages of NAT is the SNAT (Source Network Address Translation) function. Basically, this is used in the above example if we can’t afford or see any real idea in having a real public IP for each and every one of the clients. In that case, we use one of the private IP ranges for our local network (for example, 192.168.1.0/24), and then we turn on SNAT for our local network. SNAT will then turn all 192.168.1.0 addresses into it’s own public IP (for example, 217.115.95.34). This way, there will be 5-10 clients or many many more using the same shared IP address.

There is also something called DNAT, which can be extremely helpful when it comes to setting up servers etc. First of all, you can help the greater good when it comes to saving IP space, second, you can get an more or less totally impenetrable firewall in between your server and the real server in an easy fashion, or simply share an IP for several servers that are separated into several physically different servers. For example, we may run a small company server farm containing a webserver and ftp server on the same machine, while there is a physically separated machine containing a couple of different chat services that the employees working from home or on the road can use to keep in touch with the employees that are on-site. We may then run all of these services on the same IP from the outside via DNAT.

In Linux, there are actually two separate types of NAT that can be used, either Fast-NAT or Netfilter-NAT. Fast-NAT is implemented inside the IP routing code of the Linux kernel, while Netfilter-NAT is also implemented in the Linux kernel, but inside the netfilter code. Since this article won’t touch the IP routing code too closely, we will pretty much leave it here, except for a few notes. Fast-NAT is generally called by this name since it is much faster than the netfilter NAT code. It doesn’t keep track of connections, and this is both its main pro and con. Connection tracking takes a lot of processor power, and hence it is slower, which is one of the main reasons that the Fast-NAT is faster than Netfilter-NAT. As we also said, the bad thing about Fast-NAT doesn’t track connections, which means it will not be able to do SNAT very well for whole networks, neither will it be able to NAT complex protocols such as FTP, IRC and other protocols that Netfilter-NAT is able to handle very well. It is possible, but it will take much, much more work than would be expected from the Netfilter implementation.

There is also a final word that is basically a synonym to SNAT, which is the Masquerade word. In Netfilter, masquerade is pretty much the same as SNAT with the exception that masquerading will automatically set the new source IP to the default IP address of the outgoing network interface.

IP-Tables Chains:

# Chain Explanation
1 PREROUTING Packets will enter this chain before a routing decision is made.
2 INPUT Packet is going to be locally delivered. (N.B.: It does not have anything to do with processes having a socket open. Local delivery is controlled by the “local-delivery” routing table: `ip route show table local`.)
3 FORWARD All packets that have been routed and were not for local delivery will traverse this chain.“”:
4 OUTPUT Packets sent from the machine itself will be visiting this chain.
5 POSTROUTING Routing decision has been made. Packets enter this chain just before handing them off to the hardware.

IP-Tables Tables:

# Table Explanation
1 NAT The NAT table is used mainly for Network Address Translation. “NAT”ed packets get their IP addresses altered, according to our rules. Packets in a stream only traverse this table once. We assume that the first packet of a stream is allowed. The rest of the packets in the same stream are automatically “NAT”ed or Masqueraded etc, and will be subject to the same actions as the first packet. These will, in other words, not go through this table again, but will nevertheless be treated like the first packet in the stream. This is the main reason why you should not do any filtering in this table, which we will discuss at greater length further on. The PREROUTING chain is used to alter packets as soon as they get in to the firewall. The OUTPUT chain is used for altering locally generated packets (i.e., on the firewall) before they get to the routing decision. Finally we have the POSTROUTING chain which is used to alter packets just as they are about to leave the firewall.
2 MANGLE This table is used mainly for mangling packets. Among other things, we can change the contents of different packets and that of their headers. Examples of this would be to change the TTL,TOS or MARK. Note that the MARK is not really a change to the packet, but a mark value for the packet is set in kernel space. Other rules or programs might use this mark further along in the firewall to filter or do advanced routing on; tc is one example. The table consists of five built in chains, the PREROUTING, POSTROUTING, OUTPUT, INPUT and FORWARD chains.PREROUTING is used for altering packets just as they enter the firewall and before they hit the routing decision. POSTROUTING is used to mangle packets just after all routing decisions have been made. OUTPUT is used for altering locally generated packets after they enter the routing decision. INPUT is used to alter packets after they have been routed to the local computer itself, but before the user space application actually sees the data. FORWARD is used to mangle packets after they have hit the first routing decision, but before they actually hit the last routing decision. Note that mangle can’t be used for any kind of Network Address Translation orMasquerading, the nat table was made for these kinds of operations.
3 FILTER The filter table should be used exclusively for filtering packets. For example, we could DROP,LOGACCEPT or REJECT packets without problems, as we can in the other tables. There are three chains built in to this table. The first one is named FORWARD and is used on all non-locally generated packets that are not destined for our local host (the firewall, in other words). INPUT is used on all packets that are destined for our local host (the firewall) and OUTPUT is finally used for all locally generated packets.
4 RAW Iptable’s Raw table is for configuration excemptions. Raw table has the following built-in chains.


DDOS Attacks and how to handle them.

What is a DDoS attack?

DoS and DDoS attacks flood a Web server with false requests for information, overwhelming the system and ultimately crashing it. The following graphics explain how such attacks work and how companies can possibly prevent them. In effect the server can not handle all the requests, no matter how big and bad your server is. The nature of the attack is quite simple but has complex results on the machine being affected.

How a “denial of service” attack works

In a typical connection, the user sends a message asking the server to authenticate it. The server returns the authentication approval to the user. The user acknowledges this approval and then is allowed onto the server.

In a denial of service attack, the user sends several authentication requests to the server, filling it up. All requests have false return addresses, so the server can’t find the user when it tries to send the authentication approval. The server waits, sometimes more than a minute, before closing the connection. When it does close the connection, the attacker sends a new batch of forged requests, and the process begins again–tying up the service indefinitely.

Typical connection

DoS & DDoS attacks

How to block a “denial of service” attack

One of the more common methods of blocking a “denial of service” attack is to set up a filter, or “sniffer,” on a network upstream. This means before a stream of information even reaches a site’s Web servers. The filter can look for attacks by noticing patterns or identifiers contained in the information. It requires hardware for filtering. If a pattern comes in frequently, the filter can be instructed to block messages containing that pattern, protecting the Web servers from having their lines tied up.

DDoS attacks can happen to anybody!

As a webmaster or admin for any site, never ever think you are exempt from being attacked.  It can happen to anybody. Last month alone there was over 50,000 reported attacks. The attacks were directed towards major sites and small ones without regard. Twitter was taken down from such attacks just a couple weeks ago. Then the same malicious group targeted Google and Facebook.  Less than two years ago the department of defense was attacked and completely taken down. If they can take down Google, Twitter, and the US Gov they can most likely take down your site also.

Protect Your Website

To protect your site you must have hardware that can defend your servers. The problem is that it is expensive. If you find your site is being attacked and you host with one of those $5/month accounts at some cheap hosting company you will find that they will just shut down your site in the interest of protecting the other sites on there servers. You will be just flat out of luck. Make sure your hosting has the routers and firewalls in place to handle these vicious attacks.  Ask specifically about DDoS prevention before you purchase hosting if you want protection. Normal firewalls and routers WONT STOP THE ATTACKS.
Take if from me. We had a virtual server completely upgraded and screaming fast with the highest security you can imagine. But the nature of a DDoS attack does not even send up a red flag to most security prevention systems. You will most likely only notice when your site goes down or your hosting provider cuts you off. Not good at all because it is too late then!

The nature of an attack

What makes these kind of attacks almost impossible to handle without the proper hardware is that you can not just start blocking IP addresses. Because of a couple reasons. First, most of the time the IP doing the request is a real IP but most likely an IP that is not malicious. Usually the IP has been spoofed. Therefore, if you add an offending IP to your block list you may be blocking a true source of visitors. Second, the request is not what actually kills your http server. What kills the server is an incomplete “handshake”.

To explain the 3 way server handshake lets elaborate a little…

To establish a connection, TCP uses a three-way handshake. Before a client attempts to connect with a server, the server must first bind to a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. To establish a connection, the three-way (or 3-step) handshake occurs:

1. The active open is performed by sending a SYN to the server.
2. In response, the server replies with a SYN-ACK.
3. Finally the client sends an ACK (usually called SYN-ACK-ACK) back to the server.

In a DDoS attack its more like a 2 way handshake. This leaves your server hanging and waiting for the third response. What this does is flood your http server with incomplete requests. Most servers have a 30 second time out and a maxim number of connections around 300 or so. Hence, your server is doomed without protection.

DDoS attack symptoms and info

DDoS attacks generally WILL NOT eat up your bandwidth because the handshake never got completed. It just increases server load to the point of being rendered useless. Nothing ever gets sent to the requesting host so there is not usually a bandwidth issue.

DDoS attacks are basically impossible to track unless you have tons of resources. Like on a government level. One of the difficulties in tracking is because the offending IP’s are usually spoofed and do not exist or are valid IP’s that are non offending.

Blocking IP’s wont help with a DDoS attack. You must have the proper hardware to defend against DDoS attacks. If somebody know software to hand attacks please let me and the world know about it.

Who is doing such malicious attacking?

To put it bluntly there are many groups of attackers out there. Some are religious based and some are politically based. But the most notorious ones are simply groups of hackers that get paid to take down sites. They get paid between $100 and $500 per 1000 http requests. There are actually bots for hire out there… SHeeesh! I think they should be hung upside down and have there toe nails pulled out.

Conclusions about DDoS attacks

Get a hosting company that has the hardware to handle these attacks. Firewalls and fast servers just wont help. As a result of the recent attacks on DeveloWare.com and the companies that host through us we have upgraded our equipment to handle this. We can now provide protection against DDoS attacks.

TCP 3 way handshake

In this lesson, you will learn how two TCP devices synchronize using three way handshake (3 way handshake) and what are the three steps of a TCP three way handshake and how two TCP devices synchronize.

Before the sending device and the receiving device start the exchange of data, both devices need to be synchronized. During the TCP initialization process, the sending device and the receiving device exchange a few control packets for synchronization purposes. This exchange is known as a three-way handshake.

The three-way handshake begins with the initiator sending a TCP segment with the SYN control bit flag set.

TCP allows one side to establish a connection. The other side may either accept the connection or refuse it. If we consider this from application layer point of view, the side that is establishing the connection is the client and the side waiting for a connection is the server.

TCP identifies two types of OPEN calls:

Active Open. In an Active Open call a device (client process) using TCP takes the active role and initiates the connection by sending a TCP SYN message to start the connection.

Passive Open A passive OPEN can specify that the device (server process) is waiting for an active OPEN from a specific client. It does not generate any TCP message segment. The server processes listening for the clients are in Passive Open mode.

TCP Three-way Handshake

syn ack

Step 1. Device A (Client) sends a TCP segment with SYN = 1, ACK = 0, ISN (Initial Sequence Number) = 2000.

The Active Open device (Device A) sends a segment with the SYN flag set to 1, ACK flag set to 0 and an Initial Sequence Number 2000 (For Example), which marks the beginning of the sequence numbers for data that device A will transmit. SYN is short for SYNchronize. SYN flag announces an attempt to open a connection. The first byte transmitted to Device B will have the sequence number ISN+1.
Step 2. Device B (Server) receives Device A’s TCP segment and returns a TCP segment with SYN = 1, ACK = 1, ISN = 5000 (Device B’s Initial Sequence Number), Acknowledgment Number = 2001 (2000 + 1, the next sequence number Device B expecting from Device A).

Step 3. Device A sends a TCP segment to Device B that acknowledges receipt of Device B’s ISN, With flags set as SYN = 0, ACK = 1, Sequence number = 2001, Acknowledgment number = 5001 (5000 + 1, the next sequence number Device A expecting from Device B)
This handshaking technique is referred to as the Three-way handshake or SYN, SYN-ACK, ACK.

After the three-way handshake, the connection is open and the participant computers start sending data using the sequence and acknowledge numbers.

You have learned what is TCP three way hand shake (3 way handshake), the three steps of a TCP three way handshake and how two TCP devices synchronize. Click “Next” to continue.