Server

서버란?

OS에 의해 동작하는 프로세스이며, 클라이언트의 역할을 하는 프로세스와 소켓을 통해 IPC를 수행하는 것

 

시스템 콜:

응용 프로그램의 요청에 따라 커널에 접근하기 위한 인터페이스

사용자 프로그램이 디스크 파일을 접근하거나 화면에 결과를 출력하는 등의 작업이 필요한 경우,

즉 사용자 프로그램이 특권 명령의 수행을 필요로 하는 경우, 운영체제에 특권 명령의 대행을 요청하는 것이 시스템 콜

 

시스템 콜은 여러 종류의 기능으로 나누어진다, 각 시스템 콜에는 번호가 할당되고 시스템 콜 인터페이스는 시스템 콜 번호와 시스템 콜 핸들러 함수주소로 구성되는 시스템 콜 테이블을 유지한다. (시스템 콜 테이블 = 시스템 콜 번호 + 시스템 콜 핸들러 함수주소)?

 

운영체제는 자신의 커널 영역에서 해당 인덱스가 가리키는 주소에 저장되어있는 루틴을 수행한다. > 작업이 완료되면 CPU에게 인터럽트를 발생시켜 수행이 완료되었음을 알린다.

 

 

경우에 따라 시스템 콜이 발생했을때 추가적인 정보가 필요할 수도 있는데 그러한 정보가 담긴 매개변수들은 OS에 어떻게 전달할까?

가장 선호되는 방식(매개변수의 갯수나 길이의 제한이 없기 때문에 선호되는 방식):

매개변수를 메모리에 저장해 해당 메모리의 주소를 레지스터에 전달, 매개변수는 프로그램에 의해 스택에 전달.

 

 

시스템 콜의 예시

in.txt에 있는 파일 내용과 같은 내용을 복사하여 out.txt 파일을 만드는 것

위와같은 명령어를 입력하면 순차적으로 호출되는 시스템 콜은 어떤것이 있을까?

1. 먼저 사용자로부터 입력을 받는데 이때 I/O 시스템 콜 호출이 필요.

2. 이후 'cp' 프로그램을 실행시키면서 in.txt파일이 현재 디렉토리에서 접근 가능한지 확인하기 위한 시스템 콜 호출

3. 이때 접근이 불가능하다면 에러를 발생시키고 프로그램이 종료되는데 이때 시스템 콜 호출.

4. 파일이 존재해 접근이 가능하다면 복사한 파일을 저장하기 위해 out.txt 파일명이 있는지 검사하기 위한 시스템 콜 호출

5. 만약 파일명이 이미 존재한다면(파일명 존재하는지 안하는지 시스템콜 호출을 통해 확인) 덮어 씌워야할지 이어 붙어야할지 User에게 물어볼수있는데 만약 저장하고자 하는 파일 이름이 겹치지않는다면 파일을 저장해야하는데 이때도 시스템 콜 호출.

 

 

시스템 콜이 필요한 이유는?

우리가 일반적으로 사용하는 프로그램은 '응용 프로그램'이다. 유저레벨의 프로그램은 유저레벨의 함수들만으로는 많은 기능을 구현하기 힘들기 때문에 커널의 도움을 반드시 받아야한다. 

이러한 작업은 응용프로그램으로 대표되는 유저 프로세스에서 유저모드에서는 수행할 수 없다.

반드시 커널에 관련된 것은 커널모드로 전환한 후에야 해당 작업을 수행할 권한이 생긴다.

 

그렇다면 권한은 왜 필요한 것일까?

만약 권한이 없을때 해커가 피해를 입히기 위해 악의적으로 시스템 콜을 사용하는 경우나 초보 사용자가 하드웨어 명령어를 잘 몰라서 아무렇게 함수를 호출했을 경우에 시스템 전체를 망가뜨릴 수도 있기 때문이다. 따라서 이러한 명령어들은 특별하게 커널 모드에서만 실행 할 수 있도록 설계되었고, 만약 유저 모드에서 시스템 콜을 호출할 경우에는 운영체제에서 불법적인 접근이라 여기고, 트랩을 발생시킨다.

 

 

유저 모드와 커널 모드

유저 모드

PC register가 사용자 프로그램이 올라가 있는 메모리 위치를 가리키고 있을 때 현재 사용자 프로그램을 수행중이라고 하며 CPU 가 유저 모드에서 수행중이라고 말한다.

 

커널모드

PC register가 운영체제가 존재하는 부분을 가리키고 있다면 현재 운영체제의 코드를 수행중이라고 하며 CPU가 커널모드에서 수행중이라고 말한다.

 

일반 명령과 특권 명령

CPU 내에 모든 비트를 두어서 구분한다.

0 - 커널모드 / 1 - 유저모드

 

일반 명령 (유저모드)

메모리에서 자료를 읽어와서 CPU 에서 계산하고 결과를 메모리에 쓰는 일련의 명령들, 모든 프로그램이 수행 가능함.

 

특권 명령 (커널모드)

보안이 필요한 명령, 입출력 장치, 타이머 등 각종 장치에 접근하는 명령

 

 

[운영체제 / OS] 프로세스와 스레드

프로세스 : 운영체제로부터 자원을 할당 받은 작업의 단위

스레드 : 프로세스가 할당받은 자원을 이용하는 **실행 흐름의 단위

 

멀티스레드의 장단점?

 

스레드는 프로세스내에서 stack 메모리 영역을 제외한 다른 메모리 영역을 같은 프로세스 내 다른 스레드와 공유하기 때문에 메모리 낭비를 줄일 수 있다. 또한, 통신 부담이 적어 응답 속도가 빠르다.

다만, 스레드의 스케줄링은 운영체제가 처리하지 못하기 때문에 동기화 문제에 대응할 수 있어야하고, 한개의 스레드에 문제가 발생할 경우 모든 프로세스가 중단될 수 있다는 단점이 있다.

 

 

프로세스란?

실행중에 있는 프로그램

메모리에 올라와 실행되고 있는 프로그램의 인스턴스(독립적인 개체)

스케줄링의 대상이 되는 작업(task)와 같은 의미로 쓰인다.

프로세스 내부에는 최소 하나의 스레드를 가지고 있는데, 실제로는 스레드 단위로 스케줄링을 한다.

하드디스크에 있는 프로그램을 실행하면, 실행을 위해서 메모리 할당이 이루어지고, 할당된 메모리 공간으로 바이너리 코드가 올라가게된다. > 이 순간부터 프로세스라 불린다.

 

 

프로세스의 문맥

CPU 수행 상태를 나타내는 하드웨어 문맥

 

프로세스의 메모리 영역

- Code 영역 : 실행할 프로그램의 코드나 명령어들이 기계어 형태로 저장된 영역. CPU는 코드영역에 저장된 명령어들을 하나씩 처리함.

- Data 영역: 코드에서 선언한 전역 변수와 정적 변수가 저장되는 영역. 프로그램이 실행되면서 할당되고 종료되면서 소멸

- Stack 영역 : 함수 안에서 선언된 지역변수, 매개변수, 리턴값등이 저장된다. 함수 호출시 기록되고 종료되면 제거된다.

- Heap 영역 : 관리가 가능한 데이터 이외의 다른 형태의 데이터를 관리하기 위한 자유공간.

 

프로세스 관련 커널 자료구조

- PCB(Process Control Block)

- Kernel Stack

 

 

프로세스의 상태

프로세스는 상태가 변경되며 수행된다.

Running : CPU를 잡고 instruction을 수행중인 상태

Ready : CPU를 기다리는 상태

Blocked(waiting, sleep) : CPU를 주어도 당장 instruction을 수행할 수 없는 상태, Process 자신이 요청한 event가 즉시 만족되지않아 이를 기다리는 상태, 예) 디스크에서 file을 읽어와야 하는 경우

New : 디스크에서 메모리로 프로그램이 올라가 실행준비를 하는 상태

Terminated : 수행이 끝난 상태

 

 

PCB(Process Control Block)

PCB는 운영체제가 프로세스를 표현한 자료구조이다. 특정 프로세스에 대한 정보를 갖고 있다. 각 프로세스가 생성될때마다 고유의 PCB가 생성되고, 프로세스가 완료되면 PCB는 제거된다. 

프로세스간 문맥 교환이 일어나면서, 프로세스는 진행하던 작업들을 PCB에 저장하고, 이후에 자신의 순서가 왔을때 이어서 처리한다.

 

 

문맥교환(Context Switch)

하나의 프로세스가 이미 CPU를 사용중인 상태에서 다른 프로세스가 CPU를 사용하기 위해 이전 프로세스의 상태를 저장하고 새로운 프로세스의 상태를 적재하는 것.

 

예시) 카카오톡을 켜놓고 유튜브로 노래를 들으면서 웹 서핑을 하는 것은 사용자 입장에서 동시에 일어나는 일처럼 보이지만 실제로는 그렇지않음.

현재 프로세스 A가 CPU를 사용하고 있는 상황에서 CPU 사용시간이 끝나, 다음 프로세스에게 CPU를 넘겨주어야한다. 스케줄링 알고리즘에 의해 다음 CPU를 받을 프로세스 B가 선택되었고, 타이머 인터럽트가 발생해 CPU 제어권이 운영체제 커널에 넘어가게 된다.

이 과정에서 운영체제는 타이머 인터럽트 처리 루틴으로가서 직전까지 수행중이던 프로세스 A의 문맥을 자신의 PCB에 저장하고, 프로세스 B는 예전에 저장했던 자신의 문맥을 PCB로부터 실제 하드웨어로 복원 시키는 과정을 거치게된다.

CPU가 동시에 여러개의 프로세스를 실행시키는 것처럼 보이지만, 사실은 CPU가 재빠르게 여러 프로세스를 번갈아가며 실행하고 관리하고 있는것, 이때 프로세스를 번갈아가면서 처리하는 것을 Context Switching(문맥교환)이라고 한다.

 

오버헤드 : 문맥교환에 필요한 시간, 메모리

 

문맥교환이 아닌 경우?

프로세스가 실행 상태일때, 시스템 콜이나 인터럽트가 발생하면 CPU의 제어권이 운영체제에게로 넘어와 원래 실행중이던 프로세스의 업무를 잠시 멈추고 운영체제의 코드가 실행된다.

이는, 하나의 프로세스가 사용자 모드에서 실행되다가, 커널 모드로 실행 모드만 바뀌는 것일뿐 CPU를 점유하는 프로세스가 다른 사용자 프로세스로 변경되는 과정이 아니기 때문

문맥교환 x

문맥교환 o

 

스레드

프로세스 하나만을 사용해서 프로그램을 실행하기에는 메모리의 낭비가 발생한다.

스레드는 프로세스와 다르게 스레드간 메모리를 공유하며 작동한다.

즉, 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위이다. 스레드는 운영체제의 스케줄러에 의해 독립적으로 관리될 수 있는 프로그래밍된 명령어의 가장 작은 시퀀스이다. 하나의 프로세스는 하나 이상의 스레드를 갖고 있다.

 

 

프로세스와 스레드의 차이점

운영체제는 프로세스마다 독립된 메모리 영역을 Code/Data/Stack/Heap 의 형식으로 할당한다.

각각 독립된 메모리 영역을 할당해주기 때문에 프로세스는 다른 프로세스의 변수나 자료에 접근 할 수 없다.

 

이와 다르게 스레드는 메모리를 서로 공유할 수 있다.

프로세스가 할당받은 메모리 영역 내에서 Stack 형식으로 할당된 메모리 영역은 다로 할당받고, 나머지 Code/Data/Heap 형식으로 할당된 메모리 영역을 공유한다.

따라서, 각각의 스레드는 별도의 스택을 가지고 있지만 힙 메모리는 서로 읽고 쓸 수 있게된다.

 

정리해보면 프로세스는 운영체제로 부터 별도의 메모리 영역을 할당 받고, 스레드는 Stack을 제외한 Code/Data/Heap 부분은 공유해 서로 읽고 쓸 수 있게 된다.(공유 자원을 가짐)

 

이런식으로 메모리는 공유하는 이유?

스레드는 "흐름의 단위"로 CPU의 입장에서 최소 작업 단위가 된다. 

반면 운영체제는 이런 작은 단위까지 직접 작업하지 않기 때문에 운영체제 관점에서는 프로세스가 최소 작업 단위가 된다.

여기서 중요한 점은 하나의 프로세스는 하나 이상의 스레드를 가진다는 점이다. 

따라서, 운영체제 관점에서는 프로세스가 최소 작업 단위인데, 이때문에 같은 프로세스 소속의 스레드끼리 메모리를 공유하지 않을수 없다.

 

멀티태스킹, 멀티스레드

 

멀티태스킹이란 하나의 운영체제 안에서 여러 프로세스가 실행되는 것을 의미한다.

멀티태스킹은 자칫하면 여러 프로세스가 동시에 실행되는 것처럼 보이지만, 자세한 원리를 보면 그렇지 않다.

이는 운영체제의 스케줄링 방식에 의하여 설명될 수 있다.

 

멀티태스킹 : 하나의 운영체제 안에서 여러 프로세스가 실행

멀티스레드 : 하나의 프로세스가 여러 작업을 여러 스레드를 사용해 동시에 처리하는 것

 

멀티스레드의 장점 : 메모리 자원 아낄수있음, Stack 영역을 제외한 모든 메모리를 공유하기에 통신 부담이 적어서 응답 시간 빠름.

단점 : 스레드 하나가 자원 망치면 모든 프로세스가 종료될 수 있음, 동기화 문제(교착 상태가 발생하지 않도록 주의해야됨)

 

동기화 문제란? 

멀티스레드를 사용하면 각각의 스레드중 어떤 것이 어떤 순서로 실행될지 순서를 알 수 없는데 만약 A스레드가 어떤 자원을 사용하다가 B스레드로 제어권이 넘어 간 후 B스레드가 해당 자원을 수정 했을때, 다시 제어권을 받은 A 가 해당 자원에 접근하지 못하거나, 바뀐 자원에 접근하게 되는 오류임

(여러 스레드가 함께 전역 변수를 사용할 경우 발생할 수 있는 충돌을 동기화 문제)

 

 

프로세스 끼리는 정보 공유가 불가능 할까?

사실 프로세스끼리 정보를 공유하는 것은 다음 방법으로 가능함.

다만, 이 경우에는 단순히 CPU 레지스터 교체뿐만 아니라 RAM과 CPU 사이의 캐시 메모리까지 초기화 되기때문에 앞서 말했듯 자원 부담이 크다.

 

 

TCP / IP 계층

 

네트워크 통신이 이루어지는 과정을 살펴보겠다.

우리가 컴퓨터를 켠 뒤, 크롬 브라우저를 열어 네이버 웹사이트를 접속한다고 하면 아래와 같은 흐름으로 통신이 이루어진다.

1. 크롬 브라우저 검색창에서 www.naver.com  을 입력

2. 크롬 브라우저는 이를 네트워크 통신 가능한 형태로 만든다.(보통 패킷이라 부름)

3. 이 패킷을 네트워크에 흘려 보낸다.

4. 네트워크 중간에 있는 기기들이 이 패킷을 읽고 네이버 서버로 전달

5. 네이버 서버는 이 패킷을 다시 풀어, 웹서버가 읽을 수 있는 형태로 만들고 웹서버에 전달

 

중요한 점은 우리는 단순히 사람이 이해할 수 있는 URL만을 입력했지만 내부적으로 패킷과 같은 특정 형태로 데이터를 만든다는 것이다. 

또한 이렇게 만들어진 패킷은 수신받는 쪽에서 다시 사람이 이해할 수 있는 데이터로 만들어진다는 것.

 

 

osi 7계층 모델

위 과정을 OSI 7계층 모델이란 개념 위에서 표현하면 다음 그림과 같이 된다.

이 그림에서 우리는 '송신호스트'가되고 네이버 서버는 '수신 호스트'가 된다.

 

먼저 우리는 브라우저에 url을 입력한다.(응용)

이 데이터는 전송 전에 내부적으로 표현, 세션, 전송, 네트워크, 데이터 링크 계층을 차례대로 지나며 네트워크 통신에 필요한 데이터를 기존 데이터에 추가한다.

각 계층은 순서를 가지며, 응용 > 물리 계층 순으로 전달된다.

각 계층은 이전 계층으로부터 데이터를 전달 받으며, 자신의 계층에서 필요한 데이터들을 기존 데이터에 추가로 붙인다.

데이터를 붙인다는 것은 예를들어 어떤 ip로 전달할지 등의 정보를 더한다는 것이다.

물리 계층에서는 이렇게 계층을 지나며 만든 데이터를 실제로 네트워크에 전송한다.

네이버 서버는 이 데이터를 수신받아 다시 물리 > 응용 계층 순으로 전달한다

각 계층은 마찬가지로 이전 데이터로부터 데이터를 전달 받으며, 필요한 데이터만 분리하여 해석한다.

최종적으로 응용 계층에서는 요청을 웹서버에 전달한 뒤, 웹서버는 송신자에게 필요한 응답(네이버 메인 페이지)를 다시 데이터로 만들게 된다.

 

 

프로토콜

두사람과 편지를 주고받으려면 누가 누구에게 어디로, 어떤 내용인지를 우체부에게 알려줘야한다.

만약 어떤 형태로 남기자고 약속한게 이 형태라면

FROM: 보내는 사람
TO: 받을 사람
ADDRESS: 받는 사람 주소
MESSAGE: 전달할 내용

 

이 형태를 사용하려면 이렇게 써야한다.

FROM: 그랩
TO: 하디
ADDRESS: 서울시 서울숲역 디타워 5층
MESSAGE: 하디, 잘 지내고 있나요?

이제 우체부는 위 내용을 보고 이해 한 후 편지를 전달해줄것이다.

이 형태처럼 통신을 위해 형태 또는 규약을 프로토콜이라고 한다.

여기서는 두 사람과 우체부가 이 프로토콜을 사용했다고 할 수 있다.

네트워크에서는 많은 프로토콜이 있는데, 모두 데이터를 올바르게 전달하고 받기 위해 존재한다.

익히 들어본 HTTP, TCP, UDP가 바로 이러한 프로토콜의 대표적인 예시이다.

 

 

OSI 7계층 모델(국제표준화기구에서 개발한 네트워크 통신 표준 모델)

위의 네트워크 통신의 과정을 7단계의 계층으로 나눈 설계를 의미.

이렇게 계층을 나누어 놓으면 뭐가 좋을까?

전체적으로 필요한 일을 여러 계층으로 나누면 계층별 해야 할 일이 명확해진다.

전체적인 설계 모델이 있음으로써, 설명하기도 이해하기도 쉽다.

각 층을 나누면 각 층별로 필요한 데이터들을 표준화 할 수도 있다.

 

계층 7 : 응용 계층

웹서비스의 UI 부분, 사용자의 입출력 (I/O)을 담당

우리가 보통 개발하는 프론트 엔드, 백엔드 서버가 바로 이 레이어 위에서 동작함.

즉, 대부분의 사람이 사용하는 웹 서비스는 이 레이어 위에서 제공된다고 생각하면 된다.

 

계층 6 : 표현 계층

응용계층과 네트워크 계층을 위해 계층 간 데이터를 적절히 표현하는 부분을 담당

이미지 압축, 데이터 암호화등의 작업이 이 레이어에서 동작

 

계층 5 : 세션 계층

통신은 실제로 세션이라고 하는 단위 위에서 이루어지는데, 이 계층은 이러한 통신 세션을 구성

 

계층 4 : 전송 계층

컴퓨터로 들어온 네트워크 데이터를 어느 포트로 보낼지 담당

신뢰성 있는 데이터를 보장하는 역할을 담당

 

계층 3 : 네트워크 계층

IP주소를 사용하여 네트워크 데이터를 어느 컴퓨터로 보낼지 담당

라우터라는 기계가 담당

 

계층 2 : 데이터 링크 계층

네트워크 카드의 MAC 주소를 사용해 네트워크 데이터를 어느 컴퓨터로 보낼지 담당

 

계층 1 : 물리 계층

디지털 데이터를 아날로그적인 전기적 신호로 변환하여 네트워크 전선에 흘려보낸다.

 

TCP/IP 4계층 모델이란?

실제 대부분의 인터넷 통신은 IP와 TCP에 기반한 일명 TCP/IP 통신을 사용한다.

그리고 이 통신에 특화된 네트워크 통신 계층 모델이 따로 존재하는데, 이걸 TCP/IP 4계층 모델이라고 한다. OSI 7계층과 유사하지만, 아래 그림처럼 4계층으로 간소화 되어있다.

• 계층 4 : 응용 계층(Application Layer)
  • OSI 7계층 모델의 7,6,5(응용, 표현, 세션) 계층 기능을 담당한다.
  • HTTP, Telent, SSH, FTP와 같은 프로토콜이 여기에서 사용된다.
• 계층 3 : 전송 계층(Transport Layer)
  • OSI 7 계층 모델의 4(전송) 계층과 같다. 프로세스 간의 신뢰성 있는 데이터 전송을 담당한다.
  • TCP, UDP와 같은 프로토콜이 여기에서 사용된다.
• 계층 2 : 인터넷 계층 (Internet Layer)
  • OSI 7계층 모델의 3(네트워크) 계층과 같다. 컴퓨터 간 라우팅을 담당한다.
• 계층 1: 네트워크 인터페이스 계층 (Network Interface Layer)
  • OSI 7계층 모델의 2, 1(데이터 링크, 물리)계층과 같다. 네트워크 통신의 물리적인 부분들을 주로 포함한다.

 

 

HTTP vs HTTPS

HTTP는 보안에 취약하다. 그래서 통신 과정에도 응용 계층의 데이터를 암호화할 필요성이 느껴졌는데, 이로 인해 보안을 위한 레이어 SSL(Secure Sockets Layer, 현재는 TLS라는 명칭으로도 사용)가 생기게 된다. 해당 레이어는 응용 계층과 전송 계층 사이에 존재한다.

이렇게 보안의 역할을 하는 SSL 계층을 기반으로 하는 HTTP 통신을 HTTPS라고 한다.
HTTPS는 통신 보안을 포함하고 있으므로, 당연히 HTTP보다 더 좋다. 다만 내용을 암호화하고 복호화하는 로직이 추가되었으므로, 기존보다 통신 로직이 좀 더 복잡해진다.

 

 

TCP와 UDP의 차이

 

이전 글에서 보았던 것처럼 TCP와 UDP는 TCP/IP 의 전송계층에서 사용되는 프로토콜이다.

전송계층은 IP에 의해 전달되는 패킷의 오류를 검사하고 재전송 요구 등의 제어를 담당하는 계층이다.

 

TCP vs UDP

TCP는 Transmission Control Protocol의 약자이고 UDP는 User Datagram Protocol의 약자이다.

두 프로토콜은 모두 패킷을 한 컴퓨터에서 다른 컴퓨터로 전달해주는 IP 프로토콜을 기반으로 구현되어 있지만, 서로 다른 특징을 가지고있다.

TCP

UDP

TCP에 비해서 UDP가 굉장히 일반적이라는것을 볼 수 있다.

즉, 신뢰성이 요구되는 애플리케이션에서는 TCP를 사용하고 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서는 UDP를 사용한다.

 

 

 

TCP

tcp는 네트워크 계층 중 전송 계층에서 사용하는 프로토콜로서, 장치들 사이에서 논리적인 접속을 성립하기 위하여 연결을 설정하여 신뢰성을 보장하는 연결형 서비스이다.

네트워크에 연결된 컴퓨터에서 실행되는 프로그램 간에 일련의 옥텟(데이터, 메세지, 세그먼트라는 블록 단위)를 안정적으로, 순서대로, 에러없이 교환할 수 있게 한다.

 

특징:

 

연결형 서비스로 가상 회선 방식을 제공한다.

3-way-handshaking 과정을 통해 연결 설정

4-way-handshaking 을 통해 연결 해제

 

데이터 처리 속도를 조절하여 수신자의 버퍼 오버플로우 방지(흐름제어)

송신하는 곳에서 감당이 안되게 많은 데이터를 빠르게 보내 수신하는 곳에서 문제가 일어나는 것을 막는다.

수신자가 윈도우 크기 값을 통하여 수신량을 정할 수 있음

 

네트워크 내의 패킷 수가 넘치게 증가하지 않도록 방지(혼잡 제어)

정보의 소통량이 과다하면 패킷을 조금만 전송하여 혼잡 붕괴 현상이 일어나는 것을 막는다.

 

신뢰성이 높은 전송

정상적인 상황에서는 ack값이 연속적으로 전송되어야한다.

그러나 ack값이 중복으로 올 경우 패킷 이상을 감지하고 재전송을 요청한다.

일정시간동안 ack값이 수신을 못할 경우 재전송을 요청한다.

 

전이중, 점대점 방식

전이중 : 전송이 양방향으로 동시에 일어날 수 있다

점대점 : 각 연결이 정확히 2개의 종단점을 가지고 있다.

=> 멀티캐스팅이나 브로드캐스팅을 지원하지 않는다

 

TCP Header

응용 계층으로 부터 데이터를 받은 TCP는 헤더를 추가한 후에 이를 IP로 보낸다. 헤더에는 아래 표와같은 정보가 포함된다.

 

송수신자의 포트 번호	TCP로 연결되는 가상 회선 양단의 송수신 프로세스에 할당되는 포트 주소	16
시퀀스 번호(Sequence Number)	송신자가 지정하는 순서 번호, 전송되는 바이트 수를 기준으로 증가. SYN = 1 : 초기 시퀀스 번호가 된다. ACK 번호는 이 값에 1을 더한 값. SYN = 0 : 현재 세션의 이 세그먼트 데이터의 최초 바이트 값의 누적 시퀀스 번호	32
응답 번호(ACK Number)	수신 프로세스가 제대로 수신한 바이트의 수를 응답하기 위해 사용.	32
데이터 오프셋(Data Offset)	TCP 세그먼트의 시작 위치를 기준으로 데이터의 시작 위치를 표현(TCP 헤더의 크기)	4
예약 필드(Reserved)	사용을 하지 않지만 나중을 위한 예약 필드이며 0으로 채워져야한다.	6
제어 비트(Flag Bit)	SYN, ACK, FIN 등의 제어 번호 -> 아래 추가 설명 참조	6
윈도우 크기(Window)	수신 윈도우의 버퍼 크기를 지정할 때 사용. 0이면 송신 프로세스의 전송 중지	16
체크섬(Checksum)	TCP 세그먼트에 포함되는 프로토콜 헤더와 데이터에 대한 오류 검출 용도	16
긴급 위치(Urgent Pointer)	긴급 데이터를 처리하기 위함, URG 플래그 비트가 지정된 경우에만 유효	16

 

제어비트 정보

URG	긴급 위치를 필드가 유효한지 설정
ACK	응답 번호 필드가 유효한지 설정. 클라이언트가 보낸 최초의 SYN 패킷 이후에 전송되는 모든 패킷은 이 플래그가 설정되어야 한다. 자세한 내용은 아래 추가 설명 참조
PSH	수신 애플리케이션에 버퍼링된 데이터를 상위 계층에 즉시 전달할 때
RST	연결의 리셋이나 유효하지 않은 세그먼트에 대한 응답용
SYN	연결 설정 요구. 동기화 시퀀스 번호. 양쪽이 보낸 최초의 패킷에만 이 플래그가 설정되어 있어야 한다.
FIN	더 이상 전송할 데이터가 없을 때 연결 종료 의사 표시

ack 제어비트 : ack는 송신측에 대하여 수신측에서 긍정 응답으로 보내지는 전송 제어용 캐릭터

ack 번호를 사용하여 패킷이 도착했는지 확인한다 > 송신한 패킷이 제대로 도착하지 않았으면 재송신을 요구한다

 

 

TCP의 연결 및 해제

TCP connection(3-way handshake)

먼저 open()을 실행한 클라이언트가 SYN을 보내고 SYN_SENT상태로 대기한다.

서버는 SYN_RCVD 상태로 바꾸고 SYN과 응답 ACK를 보낸다.

SYN과 응답 ACK를 받은 클라이언트는 ESTABLISHED상태로 변경하고 서버에게 응답 ACK를 보낸다.

응답 ACK를 받은 서버는 ESTABLISHED 상태로 변경한다.

 

TCP disconnection(4-way handshake)

먼저 close()를 실행한 클라이언트가 FIN을 보내고 FIN_WAIT1 상태로 대기한다.

서버는 close_wait로 바꾸고 응답 ack를 전달한다. 동시에 해당 포트에 연결되어 있는 어플리케이션에게 close()를 요청한다.

ack를 받은 클라이언트는 상태를 fin_wait2로 변경한다.

close()요청을 받은 서버 어플리케이션은 종료 프로세스를 진행하고 fin을 클라이언트에 보내 last_ack상태로 바꾼다.

fin을 받은 클라이언트 ack를 서버에 다시 전송하고 time_wait로 상태를 바꾼다. time_wait에서 일정 시간이 지나면 closed된다. 

ack를 받은 서버도 포트를 closed로 닫는다.

 

반드시 서버만 close_wait상태를 갖는 것은 아니다.

서버가 먼저 종료하겠다고 fin을 보낼 수 있고, 이런 경우 서버가 fin_wait1상태가 된다

누가먼저 close를 요청하느냐에 따라 상태가 달라질 수 있다.

 

 

UDP Header

송신자의 포트 번호	16	데이터를 보내는 애플리케이션의 포트 번호
수신자의 포트 번호	16	데이터를 받을 애플리케이션의 포트 번호
데이터의 길이	16	UDP 헤더와 데이터의 총 길이
체크섬(Checksum)	16	데이터 오류 검사에 사용

 

tcp헤더와는 차별적으로 udp헤더에는 포함된 정보가 부실한 느낌이다.

udp는 수신자가 데이터를 받는지 마는지 관심이 없기 때문이다. 즉, 신뢰성을 보장해주지 않지만 간단하고 속도가 빠름.

 

udp tcp의 공통점 : 포트번호를 이용하여 주소를 지정, 데이터 오류 검사를 위한 체크섬 존재

차이점 :

TCP(Transfer Control Protocol)                                                   UDP(User Datagram Protocol)

연결이 성공해야 통신 가능(연결형 프로토콜)	비연결형 프로토콜(연결 없이 통신이 가능)
데이터의 경계를 구분하지 않음(Byte-Stream Service)	데이터의 경계를 구분함(Datagram Service)
신뢰성 있는 데이터 전송(데이터의 재전송 존재)	비신뢰성 있는 데이터 전송(데이터의 재전송 없음)
일 대 일(Unicast) 통신	일 대 일, 일 대 다(Broadcast), 다 대 다(Multicast) 통신