개발노트

AWS 리전, 가용영역

리전이란? 

aws에서 수많은 컴퓨팅 서비스를 하려면 당연히 대규모의 서버 컴퓨터를 모아놓을 곳이 필요하는데 이때 한곳에 몰아넣게 되면 2가지 문제가 생김

(자연재해 발생시 모든 서비스 마비, 모든 자원이 북미에 있다면 아시아지역에서의 서비스가 느려짐)

따라서 위 문제점 해결하기 위하여 자원을 여러곳에 분산시켜 놓은것

 

가용영역은 리전을 한번 더 분산시켜서 놓은것

 

AWS VPC

서브넷

흔히 사용되는 IPv4의 주소 체계는 클래스를 나누어 IP를 할당한다. 하지만 이 방식은 매우 비효율적이다. 

예를들어서 어떤 기관에 A클래스를 할당한다고 하면 16,777,214개의 호스트를 할당 할 수 있는데 이 기관이 100개의 호스트를 할당한다고 하더라도 16,777,114개의 호스트를 낭비하게 된다. 

이러한 비효율성을 해결하기 위해서 네트워크 장치들의 수에 따라서 효율적으로 사용할 수 있는 서브넷이 등장하게 되었다.

 

IP 주소란?

Internet Protocol의 약자로 네트워크 통신을 할때 사용되는 프로토콜.

IP 주소를 사용하는 이유는 각각의 host들을 구분하여 데이터를 정확하게 송수신하기 위함.

 

IP 주소는 IPv4와 IPv6체계로 나뉨

 

IPv4

3자리 숫자가 4마디로 표기되는 방식.

각 마디는 옥텟이라고 명칭. 

위 주소는 내부적으로 32비트로 처리됨(각 마디당 8비트)

예를들어서 192.168.123.123은 11000000.10101000.1111011.1111011로 표시됨.

IPv4는 한 옥텟당 256개(2의 8승)를 할당 할 수 있어서 4,294,967,296개의 주소를 만들수 있음(256의 4승) = 약 42억개

하지만 인터넷 환경이 발달함에 따라서 어마어마하게 많은 IP주소가 필요해져서 IPv4 주소 체계로는 IP주소를 할당하기에 힘들어졌음.

이때 새로운 주소 체계인 IPv6가 나오게됨.

 

IP 주소는 대역에 따라서 A,B,C,D,E 클래스로 나뉘는데 클래스를 구분함으로써 클래스내에서 네트워크 ID와 호스트 ID를 구분함.

A class : 대규모 네트워크 환경에 쓰이며, 첫번째 마디 숫자가 0~127 까지 사용됨

B class : 중규모 네트워크 환경에 쓰이며, 첫번째 마디 숫자가 128~191 까지 사용됨

C class : 소규모 네트워크 환경에 쓰이며, 첫번째 마디 숫자가 192~223까지 사용됨

D class : 멀티캐스팅용으로 잘 쓰이지 않는다.

E class : 연구 / 개발용 혹은 미래에 사용하기 위해 남겨놓은 클래스로 일반적인 용도로 사용되지않음.

 

A class는 하나의 네트워크가 가질수있는 호스트수가 가장 많은 클래스.

네트워크 영역은 앞 8비트가 차지하고 나머지 24비트는 호스트 영역

예를들어  18.123.123.123이라는 IP주소가 있다면 18은 네트워크 ID를 나타내고 123.123.123은 호스트 ID

첫번째 옥텟이 가질수 있는 범위는 0~127이고 1개의 네트워크 영역이 각각 가질수 있는 호스트 ID는( 2의 24승 )-2이다.

-2를 해준 이유는 시작주소는 x.0.0.0은 네트워크 주소로 사용하고 마지막 주소인 x.255.255.255는 브로드캐스트 주소로 사용되기 때문

 

예를들어서 13.x.x.x 네트워크 주소에서 호스트 영역을 할당한다고 하면 13은 네트워크 영역이고 x.x.x부분은 호스트 영역으로 0.0.0과 255.255.255를 제외한 13.0.0.1 ~ 13.255.255.254 까지 (2의 24승)-2 개를 할당할 수 있는 것이다.

 

B class는 중규모 네트워크에서 사용되는데 네트워크 영역은 앞의 16비트가 차지하고, 호스트 영역은 뒤 16비트가 차지한다.

예를들어 151.123.123.123이라는 IP 주소가 있다면 151.123은 네트워크 ID를 나타내고 123.123은 호스트 ID를 나타낸다.

첫번째 옥텟의 범위는 128~191이고 1개의 네트워크 영역이 각각 가질수있는 호스트 ID는 (2의 16승) -2 개이다.

 

C class 는 소규모 네트워크에서 사용되며 네트워크 영역은 앞의 24비트가 차지하고 호스트 영역은 뒤 6비트가 차지한다.

예를들어 201.123.123.123이라는 IP주소가 있다면 201.123.123은 네트워크 ID를 나타내고 121은 호스트 ID를 나타낸다.

첫번째 옥텟의 범위는 192~223이고 1개의 네트워크 영역이 각각 가질수 있는 호스트 ID는 (2의 8승) -2 개이다.

 

클래스 구분을 예시를 들어보면

 

132.12.11.4

클래스 : B

네트워크 영역 : 132.12

호스트 영역 : 11.4

 

10.3.4.1

클래스 : A

네트워크 영역 : 10

호스트 영역 : 3.4.1

 

203.10.1.1

클래스 : C

네트워크 영역 : 203.10.1

호스트 영역 : 1

 

 

IPv6

위에 IPv4 주소 체계만으로는 주소가 부족하여서 IPv6 가 나왔다고 말했는데, IPv6는 32비트 체계가 아닌 128비트 체계의 인터넷 프로토콜을 의미한다.

즉, 2^128 = 340,282,366,920,938,463,463,374,607,431,768,211,456 개의 주소를 할당할 수 있다.

16비트씩 8자리로 각 자리를 ':'로 구분한다.

여기서 문제는 아직까지도 IPv4에서 IPv6로의 전환이 완료되지않았다는 점이다.

아직 많은 라우터들이 IPv4를 사용한다. 

IPv6로의 전환은 많은 시간과 비용이 들기 때문에 완료되기까지 적지않은 시간이 걸릴 것이다.

현재는 IPv4와 IPv6를 혼용해서 사용하는데 IPv4 라우터에서 tunneling이라는 방식을 사용해서 IPv6 데이터그램을 전송한다.

 

다시 서브넷으로 돌아와보자.

 

서브넷은 IP주소에서 네트워크 영역을 부분적으로 나눈 부분 네트워크를 뜻한다. 이러한 서브넷을 만들때 사용되는것이 서브넷 마스크이다.

즉, 서브넷 마스크는 IP 주소 체계의 네트워크 ID와 호스트 ID를 분리하는 역할을한다. 

 

예를들어 C class는 기본적으로 앞의 24비트가 네트워크 영역, 뒤에 8비트가 호스트 영역으로 되어있는데, 이때 서브넷 마스크를 이용하면 원본 네트워크를 여러개의 네트워크로 분리할 수 있다. 이 과정을 서브넷팅이라고 한다.

각 클래스마다의 서브넷 마스크이다(D,E class는 사용하지않음)

이런 기본 서브넷 마스크를 사용하게되면 IP주소의 네트워크 id와 호스트 id를 구분할 수 있다.

IP 주소에 서브넷 마스크를 AND 연산하면 네트워크 ID가 된다.

예를들어 위에 사진처럼 저 C class의 IP주소가 있다고하면 C class의 기본 서브넷 마스크는 255.255.255.0이므로 and 연산을 해주면

네트워크 ID가 나온다. 이때 서브넷 마스크의 네트워크 ID 부분은 연속적으로 1이있어야하고 호스트ID부분은 0이 연속적으로 나와야한다.

 

예시의 IP주소를 보면 /24라는것이 붙어있는걸 볼 수 있을텐데 이것은 서브넷 마스크의 비트수(왼쪽에서부터 1의 갯수)를 나타낸다.

즉 /24는 해당 IP의 서브넷 마스크의 왼쪽에서부터 24개가 1이라는 것을 말해준다.

 

하지만 애초에 IP클래스들은 네트워크 영역이랑 호스트 영역이랑 나뉘어져있는데 굳이 서브넷 마스크가 왜 필요할까?

-> 서브넷팅을 하여 효율적인 네트워크 사용을 위해서

 

서브넷팅

서브넷팅은 IP주소 낭비를 방지 하기 위해서 원본 네트워크를 여러개의 서브넷으로 분리하는 과정을 뜻한다.

서브넷팅은 서브넷 마스크의 비트수를 증가시키는 것이라고 보면 된다. 서브넷 마스크의 비트수를 1씩 증가시키면 할당할 수 있는 네트워크가 2배수로 증가하고 호스트수는 2배로 감소한다.

예를들어서 C class 인 192.168.32.0/24를 서브넷 마스크의 비트수를 1 증가시켜서 192.168.32.0/25로 변경한다고 하면 위에 사진처럼

192.168.32.0/24는 원래 하나의 네트워크였지만 이때 할당 가능한 호스트의 수는 2의8승-2인 254개이다. 이때 서브넷 마스크의 비트수를 1 증가시켜서(서브넷팅) 192.168.32.0/25로 변경하게 되면 네트워크 id 부분을 나타내는 부분이 24비트에서 25비트로 증가하고 호스트 id를 나타내는 부분이다 8개비트에서 7개 비트로 줄어든다. 즉 할당 가능한 네트워크 수가 2개로 증가하고 각 네트워크당 할당가능한 호스트 수는 2의7승-2인 126개로 줄어든다 또한 서브넷 마스크가  255.255.255.128로 변한것을 확인할 수 있다.

 

 

211.100.10.0/24 네트워크를 각 서브넷당 55개의 Host를 할당할 수 있도록 서브넷팅 한다고 하자.

a) 서브넷 마스크를 구하시오.

호스트 id의 비트가 6개라면 2의 6승은 62개의 호스트id를 할당할 수 있으므로 충분하다.

그렇다면 32개의 비트중 26개가 네트워크 id(서브넷 마스크의 비트 갯수)이므로  1111111.11111111.11111111.11000000가 서브넷 마스크가 될것이다.

즉 255.255.255.192이다.

 

b) 서브넷의 개수를 구하시오.

 

--- 개념 추후 작성 ----

 

 

라우팅(Routing)

네트워크 세계에서 라우팅이란, 패킷에 포함된 주소등의 상세 정보를 이용하여 목적지까지 데이터 또는 메세지를 체계적으로 다른 네트워크에 전달하는 경로 선택 및 스위칭하는 과정을 이야기한다.

(= 라우팅이란 데이터가 전달되는 과정에서 여러 네트워크들을 통과해야하는 경우가 생기는데, 여러 네트워크들의 연결을 담당하고 있는 라우터 장비가 데이터의 목적지가 어디인지 확인하여 빠르고 정확한 길을 찾아 전달해주는것)

 

라우팅을 위해서 필요한 정보

 

- 출발지와 목적지의 네트워크 정보

- 목적지로 가는 모든 경로 : 출발지와 목적지 사이의 어떤 경로들이 있는지 알아야 최적경로 선택 가능

- 최적 경로 : 데이터 전달 위해서 모든 경로를 사용할 필요가 없기때문에 학습한 경로중 최적의 경로 하나 선택(이 경로 저장하는 곳은 routing table이라고 부르며 L3 장비는 이 table 정보를 사용하여 패킷 전달)

- 지속적인 네트워크 상태 확인 : 데이터 전달해주려는 경로 알지만 만약 그 경로가 다운된 상태라 사용하지 못하면 routing table에 저장된 경로로 전달이 가능한 상태인지 지속적으로 네트워킹 상태를 확인하여서 네트워크 정보를 항상 올바른 최신정보로 유지해야함.

 

 

라우팅 테이블

 

목적지까지 갈수있는 모든 가능성이 있는 경로들중에서 가장 효율이라고 판단되는 경로 정보는 패킷을 전달할때 바로 참고해서 사용할 수 있도록 따로 모아두는데 이 공간을 라우팅 테이블 이라고 한다.

라우터는 패킷의 목적지와 목적지를 가려면 어느 인터페이스로 가야하는지 자신의 라우팅 테이블에 가지고 있고, 패킷의 목적지 주소를 라우팅 테이블과 비교하여 어느 라우터에게 넘겨줄지 판단하게된다. 

따라서 라우팅 프로토콜의 가장 중요한 목적이 바로 라우팅 테이블 구성이다.

 

 

정적 라우팅과 동적 라우팅

정적 라우팅

수동으로 라우팅 테이블을 만드는것

입력된 라우팅 정보가 수정하기 전에는 이전의 값이 변하지않고 고정된 값을 유지하며 라우팅 정보는 관리자가 수동으로 입력함.

장점: 관리자에 의한 라우팅 정보만 참조하기에 부담이 없어 빠르고, 안정적, 메모리 소모도 적음, 라우터간에 데이터 교환이 없으므로 대역폭을 절약할 수 있음. 외부에 정보 노출 안하기에 보안에도 좋음

단점: 각 경로를 수동으로 추가해주어야하기에 번거롭고, 정해진 경로에 장애가 발생할 경우 네트워크 전체에 장애 발생

 

동적 라우팅

접하는 라우터들이 라우팅 정보를 서로 교환하여 라우팅 테이블을 자동으로 만드는 것.

장점: 라우터가 서로 라우팅 정보를 주고받아 자동으로 라우팅 테이블을 작성하기 때문에 관리자는 초기 설정만해주면되어서 간단함, 네트워크의 규모가 커져도 자동으로 라우팅 테이블을 갱신하기 때문에 규모가 큰 네트워크에서 사용이 가능함.

단점: 다른 라우터들과도 계속 통신하기때문에 많은 대역폭 소비

 

 

CIDR

CIDR은 클래스없는 라우팅간 도메인 기법이다. 

즉, 도메인간의 라우팅에 사용되는 인터넷 주소를 원래 IP 주소 클래스 체계를 쓰는거보다 더욱 능동의적으로 할 수 있도록 할당하여 지정하는 방식 중 하나.

IP주소 클래스를 배우면서 같이 배우는게 서브넷 마스크, 서브넷팅인데 서브넷팅과의 차이가 애매한데 서브넷팅 자체는 IP클래스에 국한되지않고 더욱 더 IP주소를 쪼개는 방식인데 이게 바로 클래스간 도메인 없는 라우팅 기법이다.

결론적으로는 서브네팅 ⊂ CIDR 이런 관계가 성립.

서브넷팅 뿐만 아니라 서브넷을 합치는 슈퍼네팅 역시 CIDR이다.

정리하자면 IP를 나누고 합치는 기술들을 다 CIDR이라고 보면 된다.

 

 

CIDR 표기법

cidr은 네트워크 정보를 여러개로 나누어진 sub-network들을 모두 나타낼 수 있는 하나의 network로 통합해서 보여주는 방법이라고 한다.

 

 

VPC

vpc는 기본적으로 가상의 네트워크 영역이기에 사설 아이피 주소를 가지게된다.

사설 아이피 대역은 10.0.0.0/8  172.16.0.0/12  192.168.0.0/24 이렇게 3개의 대역을 가지며, 하나의 vpc에는 위의 네트워크 대역, 혹은 서브넷 대역이 할당 가능하다.

 

10.0.0.0/8의 서브넷인 10.0.0.0/16도 vpc에 할당이 가능하다.

vpc는 실제로 사용시 vpc 자체에서도 서브넷을 나눠서 사용하게 된다.

예시로 10.0.0.0/16의 아이피 주소를 VPC에 할당한 상황에서,

VPC를 원하면 다시 서브넷으로 나눠서 각각 서브넷을 원하는 가용영역에 배치하여 사용하게 됨.

 

이때 vpc의 서브넷 아이피 대역에서는 실제 네트워크와 달리 총 5개의 아이피 주소를 호스트에 할당 할 수 없음.

1. 첫 주소 : 서브넷의 네트워크 대역
2. 두번째 : VPC 라우터에 할당
3. 세번째 : Amazon이 제공하는 DNS에 할당
4. 미래를 위해 예약
5. 브로드 캐스트 주소

이 5가지 항목을보고 VPC내부적으로 라우터가 있고 그렇다면 VPC 내부 서브넷끼리 통신이 된다는 것을 알아야함

 

VPC와 외부 통신

VPC가 어떻게 외부와 통신을 할까?

사설 아이피 대역은 공용 아이피 대역과 통신이 불가능하다 그런데 AWS로 인프라를 구축하면 통신이 되는 이유는 무엇일까?

Public subnet은 VPC 서브넷 중 외부와 통신이 월활하게 되는 서브넷 대역이고, Private Subnet은 외부와 통신이 되지않는 서브넷 대역이다.

 

Public subnet

AWS의 internet gateway 를 통해 해당 서브넷을 퍼블릭 서브넷이 되게 할 수 있다.

서브넷이 외부와 통신 할때, internet gateway를 거치게 하면 외부와 통신이 가능하게 한다.

이때 네트워크 패킷이 이동할때 특정 방향으로 가게한다 = 라우팅 인걸 알수 있다.

퍼블릭 서브넷으로 만들고 싶은 서브넷을 인터넷 게이트웨이를 통해 밖으로 나가도록 라우팅 테이블을 설정해주어야한다.

위 그림처럼 인터넷 게이트웨이를 만들고 라우팅 테이블에서 

Destination : 0.0.0.0/0(모든 IP주소를 의미 = 외부 모든 아이피 = 밖으로 나갈때)

Target : 만들어둔 인터넷 게이트 웨이 식별자(해당 그림에서는 igw-1234567901234567)

이렇게 만들어진 라우팅 테이블을 내가 원하는 서브넷에 연결하여 퍼블릭 서브넷을 만들게 된다.

 

Destination: 10.0.0.0/16 = 목적지: 10.0.0.0/16(VPC 주소 = VPC로 들어올때)

Target: Local = (내부 VPC 라우터가 알아서 잘 보내줌)

 

Private Subnet

 

퍼블릭 서브넷과 달리, 아무런 조치를 취하지않아 (VPC가 기본적으로 사설 아이피) 외부와 단절된 서브넷

 

그럼 private subnet은 무슨 의미가 있을까?

 

사설 아이피 대역의 역할

1. 부족한 아이피 주소 문제를 완화

한국은 NAT이라는 서비스를 사용할 수 있는데 사실 공용 아이피 주소는 공유기에만 할당이되고, 공유기에 연결한 디바이스들은 사설 아이피 대역을 받게된다.

외부 인터넷은 공유기로 먼저 데이터를 보내고, 공유기는 포트를 통해 각 디바이스들을 구분하여 데이터를 보내주게 된다.

공유기의 80번 포트는 192.168.0.1 이 할당된 노트북

공유기의 8080번 포트는 192.168.0.2가 할당된 PC가 연결된 것

 

포트포 워딩이란?

하나의 공용 아이피 주소를 가진 공유기가 자신의 포트를 통해 올바른 사설 아이피 주소를 가진 디바이스에게 데이터를 주는 것.

 

 

2. 높은 보안성

외부 네트워크의 디바이스는 공유기 뒤에 사설 아이피를 가지고 있음.

이 숨어있는 디바이스로 직접 데이터를 절대 전송할 수 없고, 무조건 공유기를 거쳐야한다.

이때 공유기가 이상한 데이터는 버려준다면 이는 보안성 측면에선 좋다.

 

Private subnet을 사용하는 이유는 소중한 자원의 보호 때문입니다.

우리가 프로젝트를 진행하며 인프라를 구축할 때는 사실 Private subnet을 사용하지 않아도된다.

하지만 릴리즈 서버의 경우는 실제 고객의 데이터가 저장되는 데이터베이스를 보호해야하므로,

데이터베이스를 private subnet에 배치하는 것이 필요하다.

 

그럼 2가지 의문이 생기게되는데

1. private subnet에 두면 외부와 통신이 안되는데 그럼 데이터 베이스를 못쓰는거 아닌가?

2. 데이터베이스에 원격으로 접속하고싶은데 안되나?

이다.

 

1번은 데이터 베이스를 사용하는 (DB에 데이터를 저장하려는) EC2등과 같은 컴퓨팅 자원을 같은 VPC에 배치하면된다.(같은 VPC의 서브넷은 통신이 가능하다)

2번은 private subnet의 bastion host 개념을 이해하면되는데

릴리즈 인프라에서 사용될 데이터베이스를 보호하기 위해서 private subnet에 배치하였고, 실제로 데이터가 잘 저장이 되었는지 mysql workbench 혹은 datagrip으로 원격 접속하여 직접 눈으로 편하게 확인하고싶은데 database는 private subnet에 위치하여 데이터그립으로는 절대 원격접속이 안되는 상황이다. 이럴 경우 private subnet과 같은 VPC에 존재하는 public subnet의 도움을 받으면 된다.

이때 private subnet의 자원에 접속이 되도록 도와주는 호스트를 bastion host라고 한다.

 

실제로 데이터그립으로 private subnet의 데이터 베이스에 원격 접속을 하기 위해서는 SSH 터널링이라는 기술이 필요하나, 데이터그립에서 아주 쉽게 설정이 가능하다.

서버란?

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

 

시스템 콜:

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

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

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

 

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

 

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

 

 

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

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

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

 

 

시스템 콜의 예시

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

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를 점유하는 프로세스가 다른 사용자 프로세스로 변경되는 과정이 아니기 때문

 

스레드

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

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

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

 

 

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

운영체제는 프로세스마다 독립된 메모리 영역을 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

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) 통신