See also section Some Details on How Terminals Work
Each terminal is connected to a serial port on the host computer (often just a PC). The ports have names/numbers. The first few are: ttyS0, ttyS1, ttyS2, etc.
These are represented by special files found in the /dev (device) directory. ttyS0) corresponds to COM1 in DOS or Windows. ttyS1) is COM2, etc. See Terminal Special Files for details on these and related "devices".
When the host computer starts up it runs the program getty. The getty program runs the "login" program to log people in. See Getty (used in /etc/inittab). A "login:" prompt appears on the screen. People at the terminals and/or console log in (after giving their passwords) and then have access to the computer. When it's time to shut the terminal down, everyone must log off and (and power off their terminal). See Login Restrictions regarding restricting logins (including allowing the root user to log in at terminal).
If one watches someone typing at a terminal, the letters one types simultaneously appear on the screen. A naive person might think that what one types is being sent directly from the keyboard to the screen with a copy going to the computer (half-duplex like, see next paragraph). What is usually going on is that what is typed at the keyboard is directly sent only to the host computer which in turn echoes back to the terminal each character it receives (called full-duplex). In some cases (such as passwords or terse editor commands) the typed letters are intentionally not echoed back.
Full-duplex means that there are two (dual) one-way communication links. Full-duplex is the norm for terminals. Half-duplex is half of a duplex, meaning that there is only a single one-way communication link. This link must be shared by communications going in both directions and only one direction may be used at a time. In this case the computer would not be able to echo the characters you type (and send to it) so the terminal would need to also send each character you type directly to the terminal screen. Some terminals have a half-duplex mode of operation which is seldom used.
The image on a CRT tube will fade away almost instantly unless it is frequently redrawn on the screen by a beam of electrons shot onto the face of the tube. Since text sent to a terminal needs to stay on the screen, the image on the screen must be stored in the memory chips of the terminal and the electron beam must repeatedly scan the screen (say 60 times per second) to maintain the image. See Terminal Memory Details for more details.
The terminal is under the control of the computer. The computer not only sends the terminal text to display on the screen but also sends the terminal commands which are acted on. These are Control Codes (bytes) and escape sequences. For example, the CR (carriage return) control code moves the cursor to the left hand edge of the screen. A certain escape sequence (several bytes where the first byte is the "escape" control code) can move the cursor to the location on the screen specified by parameters placed inside the escape sequence.
The first terminals had only a few such commands but modern terminals have hundreds of them. The appearance of the display may be changed for certain regions: such as bright, dim, underline, blink, and reverse video. A speaker in a terminal can "click" when any key is pressed or beep if a mistake has occurred. Function keys may be programmed for special meanings. Various fonts may exist. The display may be scrolled up or down. Specified parts of the screen may be erased. Various types of flow control may be used to stop the flow of data when bytes are being sent to the terminal faster than the terminal can handle them. There are many more as you will see from looking over an advanced terminal manual or from the Internet links Esc Sequence List
While terminals made for the US all used the same ASCII code for the alphabet (except for IBM terminals which used EBCDIC), they unfortunately did not all use the same escape sequences. This happened even after various ANSI (and ISO) standards were established since these standards were never quite advanced enough. Furthermore, older terminals often lacked the capabilities of newer terminals. This might cause problems. For example, the computer might send a terminal an escape sequence telling it to split the screen up into two windows of specified size, not realizing that the terminal was incapable of doing this.
To overcome these problems a database called "termcap" (meaning "terminal capabilities") was established. Termcap was later superceded by "terminfo". This database resides in certain files on the computer and has a section of it (sometimes a separate file) for each model of terminal. For each model (such as VT100) a list of capabilities is provided including a list of certain escape sequences available. For example blink=\E5m means that to make the cursor start blinking the terminal must be sent: Escape 5 m. See Section Termcap and Terminfo (detailed) for more details. Application programs may utilize this database by calling certain C-Library functions. One large set of such programs (over 200) is named "ncurses" and are listed in the manual page for "ncurses" which comes with a developer's ncurses package. There is also a NCURSES-programming-HOWTO.
The environment variable TERM is the type of terminal Linux thinks you are using. Most application programs use this to look up the capabilities in the terminfo database so TERM needs to be set correctly. But there is more to a correct interface than the computer knowing about the capabilities of the terminal.
For bytes to flow from the computer to the terminal the terminal must be set to receive the bytes at the same baud rate (bits per second) as they are sent out from the terminal. If the terminal is set to receive at 19,200 baud and the computer sends out characters at 9600 baud, only garbage (or perhaps nothing) will be seen on the screen. One selects the baud rate for a terminal (as well as many other features) from the terminals "set-up" menus at the terminal. Most terminals have a large number of options in their "set-up" menus (see Terminal Set-Up (Configure) Details). The computer serial port has options also and these options must be set up in a compatible way (see Computer Set-Up (Configure) Details.
Most terminals today have more than one emulation (personality or "terminal mode"). The terminal model numbers of terminals formerly made by DEC (Digital Equipment Corporation now Compaq) start with VT (e.g. VT100). Many other terminals which are not VT100 may be set up to emulate a VT100. Wyse was a major terminal manufacturer until about 2005. Most of their terminals can emulate various DEC terminals such at VT100 and VT220. Thus if you want to, say, use a VT320 terminal you may either use a real VT320 in "native" personality or possibly use some other terminal capable of emulating a VT320.
The "native" personalities usually have more capabilities so, other things being equal, "native" is usually the best to use. But other things may not be equal. Since the Linux console emulates a VT102 it you may want to have a terminal emulate this (or something close to it such as VT100). This will help insure that some programs that may not handle terminals properly will still work OK on your terminal. Some programs will assume that you are using a VT102 if the program can't find a terminfo for your terminal (or can't find a certain capability). Thus the failure of a program to work correctly with your non-vt102 terminal may well be your fault if you don't provide a good terminfo file for your terminal. Using "native" and then reporting any bugs will help discover and fix bugs which might not otherwise get detected.
The most common type of emulation is to use a PC like it was a vt100 terminal (or the like). Programs loaded into the PC's memory do the emulation. In Linux (unless you're in X Window) the PC monitor (called the console) emulates a terminal of type "Linux" (close to vt100). Even certain windows within X Window emulate terminals. See Terminal Emulation.
On a PC, the monitor is normally the console. It emulates a terminal of type "Linux". One logs on to it as a virtual terminal. See The Console. It receives messages from the kernel regarding booting and shutdown progress. One may have the messages that normally go to the console, go to the terminal. To get this you must manually patch the kernel, except that for kernel 2.2 (or higher) it is a "make config" option. See Make a Serial Terminal the Console.