hanbin.dev

7. 애플리케이션 계층

통신 가능한 프로그램을 만드는 것을 네트워크 프로그래밍이라 하는데, 이를 통해서 자신만의 Application Layer를 만들 수 있다.

데이터에 status code 등의 정보를 헤더에 붙여준다.

대표적인 프로토콜로는 HTTP, SMTP, FTP 등이 있다.

6. 표현 계층

표현 계층은 데이터의 구성 방식을 결정한다.

하는 일은 암호화, 복호화, 압축 등이 있다.

대표적인 프로토콜로는 JPEG MPEG 등이 있다. JPEG는 이미지를 위해 만들어진 표준 규격이며, MPEG는 멀티미디어를 위해 만들어진 표준 규격이다.

5. 세션 계층 (Session layer)

세션 계층은 양 끝단의 응용 프로세스 연결을 설립 및 해제하기 위해 필요하다.

하는 일은 세션 설정 및 해제, 세션 메세지 전송 등이 있다.

대표적인 프로토콜로는 SSH가 있다.

4. 전송 계층 (Transport layer)

전송 계층을 목적지에 신뢰할 수 있는 데이터를 전달하기 위해 필요하다.

하는 일은 데이터의 애플리케이션 목적지 식별, 오류 점검 등이 있다. 

애플리케이션 목적지 식별

해당 데이터가 어떤 애플리케이션에서 사용하는 데이터 인지 판단해서 알맞은 프로그램에 전송한다.

오류 점검

전송 계층은 데이터가 신뢰할 수 있는지 확인 한다고 했다.

데이터가 제대로 도착했는지 확인 하고 오류가 발생하면 데이터를 재전송 하도록 요청한다 (TCP 의 경우)

TCP

연결 지향적이며 만약 데이터에 문제가 있으면 다시 요청을 하기 때문에 신뢰성을 보장한다. (3 Way Handshake를 거쳐 가상 회선을 설립한다.) 참조 링크

UDP

비연결 지향적이며, 데이터에 문제가 있어도 다시 요청을 하지 않는다. 주로 실시간 스트리밍 서비스를 구현할 때 사용된다. 연속성을 보장한다. (여러 절차가 생략되어 있기 때문에 TCP에 비해 속도가 빠르다)

3. 네트워크 계층 (Network layer)

네트워크 계층에서는 최종 목적지 까지 경로를 설정하는 역할을 수행한다. 이때, 경로 설정 작업을 라우팅이라고 한다.

라우팅

Internetwork을 통하여 목적지로 데이터가 전달 될 수 있도록 하는 기능을 말한다.

라우터가 패킷을 목적지까지 전달할 수 있도록 하려면 라우터는 해당 목적지에 대한 경로 정보를 알고 있어야 하며, 이 정보에 따라 패킷을 전달한다.

따라서 라우터들은 목적지에 대한 정보를 가지고 이웃의 라우터들과 정보를 교환하는데, 이때 라우터들끼리 경로 정보를 교환하는 프로토콜을 라우팅 프로토콜이라고 한다. 

어느 컴퓨터에게 데이터를 전송할 지 IP주소를 데이터의 헤더에 붙인다.

2. 데이터 링크 계층(Data link layer)

데이터 링크 계층에서는 MAC 주소를 사용하여 신뢰성 있는 정보를 전송한다.

하는 일은 에러 검출, 흐름 제어, Framing등이 있다.

🤔MAC(Media Access Control) 주소란?

-> 랜에 사용되는 네트워크 모델인 이더넷의 물리적인 주소로, 컴퓨터 네트워크에서 각각의 기기를 구분하기 위해 사용하는 주소이다. 제조할 때 새겨지기 때문에 물리 주소 라고도 불린다.

에러 검출

에러가 발생 했을 시에 두가지 동작을 할 수 있다.

1. 다시 송신측에게 데이터 재전송을 요청하는 방식

2. 스스로 오류 복구를 하는 방식

-> 해밍코드등의 방식을 이용해 스스로 오류를 복구한다.

🤔해밍코드?

-> 자기 정정 부호로써, 오류를 검출해서 1비트의 오류를 수정 할 수있다.

흐름 제어

송신 측이 수신 측의 데이터 처리 속도 보다 훨씬 빠른 속도로 데이터를 보내면 수신측의 버퍼가 매우 길어 지고,

버퍼의 길이는 제한되어 있기 때문에 데이터가 손실 될 것이다.

그렇기 때문에 송신측에게 조금 천천히 보내달라고 요청할 수 있다. 이것이 흐름제어다.

🤔버퍼(Buffer)?

-> 데이터 흐름의 속도 차이를 조정하기 위해 일시적으로 데이터를 기억하는 장치이다.

Framing

0101 1010 1101 1010 ... 와 같은 데이터의 어디가 시작이고 어디가 끝인지 알아보기 힘들다. 그렇기 때문에 데이터에 헤더(header)와 트레일러(trailer)를 덧붙여서 데이터 프레임을 만든다.

데이터 링크 계층의 프로토콜 중에 이더넷이 있는데 이 방식에서는 목적지, 출발지 MAC 주소를 포함한 이더넷 헤더와 트레일러를 붙인다.

1. 물리 계층(Physical layer)

서버와 클라이언트가 "01100110"이라는 정보를 주고 받으려면 먼저 전기적 신호로 변환을 해야한다.

물리 계층에서는 데이터에 문제가 있는지 확인은 하지 않고, 그저 정보를 전기적 신호로 변환해 송수신을 한다.

데이터 전송 장비로는 통신 케이블, 리피터(신호를 증폭시켜줌), 허브(3대 이상의 PC를 연결시킴) 등이 있다.

프로그래머스에 들아가서 로그인 버튼을 누르면, 위와 같은 화면이 나온다.

저기서 만약 Github으로 계속하기 버튼을 누른다면, Github 로그인 페이지로 이동하게 된다.

그리고 그곳에서 Github 로그인을 하면 프로그래머스 서비스를 이용할 수 있게 된다.

나는 분명 Github 로그인을 했는데 왜 프로그래머스 서비스를 이용할 수 있는 걸까?

이것에 대해 알려면 OAuth를 알아야 한다.

OAuth란?

로그인을 제공하는 플랫폼(Github)의 계정만 있다면 외부 서비스(프로그래머스) 에서도 인증을 가능하게 하여 API를 사용할 수 있도록 해주는 프로토콜이다. 그렇기 때문에 Github 로그인을 했는데도 프로그래머스의 서비스를 사용할 수 있게 된 것이다.

OAuth가 무엇인지 알았다면 이제 OAuth의 인증 절차에 대해 알아보자

OAuth 인증 방식

용어 정리

인증 절차

1. Resource Owner가 Authorization Server에서 보내준 Github 로그인 페이지에 ID/PW 정보를 입력한다.
2. Authroization Server가 Authorization Code를 Redirect URL에 결합시켜 헤더에 담아 Resource Owner에게 전달한다.
   • ex) { "Location" : "http://my-app.com?code=thisisauthorizationcode" }
   • Authorization Code는 짧은 시간 안에 만료된다 (약 10분)
3. Resource Owner가 Redirect URL에 리다이렉트하면 Client가 Client ID , Client Secret , code, Redirect URL 정보를 Authroization Server에게 전달해 Access Token 발급 요청을 한다.
4. Access Token이 발급되었다면 Resource Owner에게 전달하며 로그인을 성공시킨다

리소스 요청

이후에 Resource Owner가 Client에게 요청할 때마다 Access Token을 요청에 포함시킨다.

TCP는 UDP와 달리 정확하게 데이터가 전달되어야 하는 통신이다. 그렇기 때문에 클라이언트와 서버간의 확인 절차가 존재하는데, 그 방법 중에 3 Way Handshake가 있다.

동작 방식

SYN = Synchronize sequence number(요청), ACK = Acknowledgement(수락)

1. Client -> Server

- Client가 Server로 연결 요청 메세지 SYN(1044)를 보낸다.

2. Server -> Client

- Server가 Client로 클라이언트의 요청을 수락 ACK(1044 + 1)한다.

  -> Server는 연결이 확립된다. (Established)

- Server가 Client로 연결 요청 SYN(4812)를 보낸다.

3. Client -> Server

- Client가 Server로 서버의 요청을 수락 ACK(4812 + 1)한다.

  -> Client도 연결이 확립된다. (Established)

🤔 왜 SYN에 +1을 해서 보낼까?

SYN + 1 한 값이 수신자가 예상하고 있는 값이기 때문이다.

이게 무슨 의미이냐면, 1044를 보내고 1045를 기다리는 것이다.

만약 1045가 아닌 다른 값이 도착한다면 연결을 하지 않을 것이다.

링크 참고

2 Way Handshake는 왜 안 되는거지?

단순히 서버와 클라이언트가 서로의 존재를 알리기 위해서는 2번의 과정만으로 충분하다고 생각할 수도 있다. 아래 그림을 보자

TCP 통신은 양방향성을 띠고 있는 통신이다. Client와 Server가 모두 존재를 알리고 패킷을 보내고 받을 수 있다는 것을 서로에게 알려야 한다.

만약 위와 같이 2 way handshake를 한다면,

  1. Client는 Server에게 연결 요청을 한다.

  2. Server는 그것에 대한 응답을 한다. -> Client의 연결 확립 (Established)

이런 흐름이 될 것이다.

이게 그냥 보기에는 문제가 없어보인다. 하지만 한가지 가정을 들어보자.

만약 1번 과정이 매우 오래전에 일어났던 일이라 Client가 비가용 상태에 돌입했다면 Server는 아무것도 모르고 세션을 확립할 것이다.

그렇기 때문에 마지막에 Client가 Server에게 "나는 가용 상태이다" 라는 사실을 알려줘야 한다.