It means you can log in to your container using TTY, ie terminal. It's as if you've got a Linux machine in front of you and you're logging into it. If you have a container that's not running SSH server or telnet, this is your only mode of getting into the command line prompt.
As for why -i and -t are different arguments I'm not sure about, I can't imagine a scenario where you want to connect using TTY and don't want the stdin/stdout option or vice versa.
stdin, stdout, and ttys are related concepts. stdin and stdout are the input and output streams of a process. A pseudo terminal (also known as a tty or a pts) connects a user's "terminal" with the stdin and stdout stream, commonly (but not necessarily) through a shell such as bash. I use quotes around "terminal" since we really don't use a terminal in the same sense today.
In the case of docker, you'll often use -t and -i together when you run processes in interactive mode, such as when starting a bash shell. In the case of the shell you want to be able to issue commands and read the output.
We can see what is happening under the hood by using the lsof command. For a demonstration we can create a simple docker container from a Debian image that just runs sleep:
docker run -d --name tty-test debian /bin/bash -c "sleep 1000"
This will start the sleep command in a new container (note that we did not use -i or -t).
Next we "login" into our container though the exec command and start a bash:
docker exec -it tty-test /bin/bash
A plain debian image will not have lsof installed so we need to install it:
apt update && apt install -y lsof
Next we run lsof:
lsof
If run without any options, lsof will print open files for all running processes. You should see three processes in its output (sleep, bash, and lsof itself).
Here are the relevant lines are those that show the file descriptors (FD column) 0 to 2.
Note how the sleep process, which we started without the -t option has three FIFO pipes for stdin,stdout and stderr:
Note how the type column has changed to CHR and the name column shows /15.
Finally, when we omit the -t option from the exec command and like this:
docker exec -it tty-test /bin/bash
then we can notice two things. First, we do not get a shell prompt from the bash now, but we can still type commands and see their output. When we run lsof we see that the bash process now also has pipes rather then a tty attached to stdin, stdout, and stderr
Simply put it allows us to attach and detach from the containers terminal. To attach we use the docker attach command and to detach we use the CTRL+P & CTRL+Q command.
Option -i -t is useful for interacting with certain interactive process's like bash shell running inside the container.
consider the below command
PS C:\Users\nssh> docker run -it ubuntu /bin/bash
root@c7537bbf2941:/# ls
bin boot dev etc home lib lib32 lib64
When we run this command, docker will start the ubuntu container with bash shell running inside.
The -i flag tells docker that anything we type should be sent to bash process's stdin. ls command typed above is sent to bash.
The -t flag tells docker that this will be an interactive session and the stdin will be a tty.
For a typical SSH like experience, -t and -i must be used together.
The only reason to leave out -t is if the stdin is a pipe (and not a tty like above). Specifying -t is forbidden when the client is receiving its standard input from a pipe, as in:
PS C:\Users\nssh> echo test | docker run -it ubuntu cat
the input device is not a TTY. If you are using mintty, try prefixing the command with 'winpty'
Leave out the -t flag if stdin is a pipe.
PS C:\Users\nssh> echo test | docker run -i ubuntu cat
test