프론트엔드Explorer

이번 포스팅에서는 HTTP 응답 헤더에 대해 알아보자. 

(지난 HTTP 공통 헤더, 요청 헤더 포스팅과 이어집니다.)

2021.05.27 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 공통 헤더와 요청 헤더

응답 헤더 

Access-Control-Allow-Origin

프론트엔드 개발자들이라면 많이 보았을 헤더이다. 프론트 주소와 백엔드 주소가 다르면 CORS 에러가 발생하는데,

이때 서버에서 응답 메시지 Access-Control-Allow-Origin 헤더에 프론트 주소를 적어줘야 에러가 나지 않는다. 

프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS 에러가 난다. 

만약, 주소를 일일이 지정하기 싫다면 위처럼 *으로 모든 주소에 CORS 요청을 허용하면 된다.

단, 그만큼 보안이 취약해진다. 

유사한 헤더로 Access-Control-Request-Method, Access-Control-Request-Headers, Access-Control-Allow-Methods, Access-Control-Allow-Headers 등이 있다. 

CORS 요청 시에는 미리 OPTIONS 주소로 서버가 CORS를 허용하는지 물어본다.

이때, Access-Control-Request-Method로 실제로 보내고자 하는 메서드를 알리고, 

Access-Control-Request-Headers로 실제로 보내고자 하는 헤더들을 알린다. 

Allow들은 Request에 대응되는 것으로, 서버가 허용하는 메서드와 헤더를 응답하는데 사용된다.

Request와 Allow가 일치하면 CORS 요청이 이루어지는 것이다. 

Allow

Allow 헤더는 Access-Control-Allow-Methods와 비슷하지만, CORS 요청 외에도 적용된다는 것에 차이가 있다.

즉, GET은 되고, POST는 허용하지 않는 경우, 405 Method Not Allowed 에러를 응답하면서 헤더로 아래와 같이 보내면 된다. GET 요청만 받겠다는 뜻이다. 

Allow: GET

Content-Disposition

응답 본문을 브라우저가 어떻게 표시해야 할지 알려주는 헤더이다. 

inline인 경우 웹페이지 화면에 표시되고, attachment인 경우 다운로드된다. 

Content-Disposition: inline
Content-Disposition: attachment; filename='filename.csv'

다운로드되길 원하는 파일은 attachment로 값을 설정하고, filename 옵션으로 파일명까지 지정해줄 수 있다. 

Location

300번대 응답이나 201 Created 응답일 때 어느 페이지로 이동할지를 알려주는 헤더이다. 

HTTP/1.1 302 Found
Location: /

위와 같은 응답이 왔다면, 브라우저는 / 주소로 리다이렉트한다. 

Content-Security-Policy

다른 외부 파일들을 불러오는 경우, 차단할 소스와 불러올 소스를 여기에 명시할 수 있다. 

하나의 웹 페이지는 다양한 외부 소스들을 불러온다. 이미지도 불러오고, script 태그로 자바스크립트 파일들도 불러온다. 폰트나 스타일, 아이프레임도 불러온다. 

하지만 해커들에 의해 원하지 않는 파일을 불러오게 될 수도 있다. 

악성코드가 담겨있는 파일이라면 문제가 발생할 것이다. XSS 공격 같은 것이 하나의 예시이다. 

이럴 때, Content-Security-Policy로 허용할 외부 소스만 지정할 수 있다. 

Content-Security-Policy: default-src 'self'
Content-Security-Policy: default-src https:
Content-Security-Policy: default-src 'none'

self로 지정하면 자기 도메인의 파일들만 가져올 수 있다. www.abc.com에서는 www.abc.com/logo.jpg를 가져올 수 있지만, www.def.com/logo.jpg는 가져올 수 없다.  

https://로 지정하면 https를 통해서만 파일을 가져올 수 있게 된다. 

'none'으로 지정하면 가져올 수 없다. 

default-src는 모든 외부 소스에 대해 적용된다. 각각 따로 지정할 수도 있다. 두 개나 세 개로만 추려서 지정할 수도 있다. 

Content-Security-Policy: font-src 'self'; script-src https://www.zerocho.com 'unsafe-inline'; 
img-src 'self'; style-src 'self' 'unsafe-inline'; object-src 'none'

font-src, script-src, img-src, style-src, object-src 등이 있고, 소스 옵션으로는 도메인이나, https://, 'unsafe-inline'(인라인 태그 허용), 'unsafe-eval'(eval 함수 허용) 등이 있다. 

옵션은 매우 다양하므로 아래 링크를 참고해보자. 

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy

이 외에도 다양한 응답 헤더들이 있다. 오늘은 유명한 응답 헤더들만 정리해보았다. 

다음 포스팅에서는 쿠키와 캐시 헤더에 대해 알아보도록 하자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

이 포스팅은 아래 링크를 참고했습니다. 

https://www.zerocho.com/category/HTTP/post/5b4c4e3efc5052001b4f519b

앞 내용을 잠시 복습해보자면, 서버의 역할은 클라이언트로부터 요청을 받아 응답을 보내는 것이다. 요청과 응답은 메세지 형식으로 오고, 이게 바로 HTTP 메시지! HTTP 메시지는 시작줄, 헤더, 본문으로 구성되어 있다. 

HTTP에 대해 알고싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/38

HTTP 메소드에 대해 알고 싶다면, 아래 포스팅을 클릭해보자. 

https://dolphinsarah.tistory.com/39

이번 시간에는 헤더에 대해 알아볼텐데, 헤더 종류가 매우 많기 때문에, 알아두면 유용한 HTTP 공통 헤더와 요청 헤더에 대해 먼저 알아보도록 하자. 

헤더는 개발자도구(F12)의 네트워크 탭에서 확인할 수 있다! 

공통 헤더 

요청과 응답 모두 사용되는 헤더이다. 

Date

HTTP 메시지가 만들어진 시각이다. 자동으로 만들어진다. 

Connection

HTTP/2를 사용하지 않는다면 보통 HTTP/1.1을 사용한다. 

Connection은 기본적으로 keep-alive로 되어 있는데 사실상 아무런 의미도 없다. 

HTTP/2에서는 아예 사라져버렸다. 

Cache-Control

매우 중요하고, 꼭 알아둬야 하는 헤더이기 때문에 아래 포스팅에 따로 정리했다. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 쿠키, 캐시 헤더

*Content 시리즈는 엔티티 헤더라고 불린다. 

Content-Length

요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해준다.

메시지 크기에 따라 자동으로 만들어진다.

Content-Length: 52

Content-Type

컨텐츠의 타입(MIME)과 문자열 인코딩(UTF-8 등)을 명시할 수 있다. 

조금 뒤에 나오는 Accept 헤더, Accept-Charset 헤더와 대응된다. 

 위의 예시 헤더는 현재 메시지 내용이 text/html 타입이고, 문자열은 utf-8 문자열임을 알려준다. 

Content-Language

사용자의 언어를 뜻한다. 요청이나 응답이 무슨 언어인지와는 관련 없다. 

예를 들어, 한국인에게 일본어를 가르치는 사이트일 경우, 페이지 언어는 일본어일지라도

Content-Language는 ko-KR일 수 있다. 

Content-Encoding

Content-Encoding은 컨텐츠의 압축된 방식이다. 

응답 컨텐츠를 br, gzip, deflate 등의 알고리즘으로 압축해서 보내면, 브라우저가 알아서 해제해 사용한다. 

이외에도 다양한 압축 알고리즘이 존재한다. 컨텐츠의 용량이 줄어들기 때문에 압축을 권장한다. 

요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 가능하면 압축해두는 게 좋다. 

요청 헤더

Host

서버의 도메인 네임이 나타나는 부분이다. (포트 포함) 

Host 헤더는 반드시 하나가 존재해야 한다. 

User-Agent

Host보다 더 유명한 헤더는 User-Agent다. 

현재 사용자가 어떤 클라이언트(운영체제와 브라우저 같은 것)를 이용해 요청을 보냈는지 나온다. 

아래의 이미지를 보면 내 클라이언트가 무엇인지 알 수 있다. (나는 LG gram 크롬으로 접속했다)

물론, User-Agent를 믿어서는 안된다. 헤더를 변경할 수도 있으니까. 

하지만 대부분의 사람들이 User-Agent를 조작하지 않고 그대로 보내기 때문에,

User-Agent 헤더를 활용해서 접속자 통계 등을 내곤 한다. 

또, 이를 활용해 IE로 접속한 사람들을 찾아내고, IE는 지원하지 않으니 크롬으로 접속해달라는 메시지를 표시하기도 한다. 

Accept

이제, Accept 시리즈를 알아보자. 

Accept 헤더는 요청을 보낼 때 서버에, 이런 타입(MIME)의 데이터를 보내줬으면 좋겠다고 명시할 때 사용한다. 아래처럼 콤마로 여러 타입을 동시에 적어줄 수도 있다. 

위와 같이 요청 헤더를 보낸다면, html 형식, xhtml+xml 형식 등등의 응답을 처리하겠다는 뜻이다. 

Accept 시리즈라고 한 것은, Accept-Encoding, Accept-Charset, Accept-Language 등도 있기 때문이다. 

공통 헤더의 Content 시리즈와 대응된다. 

Accept로 원하는 형식을 보내면, 서버가 그에 맞춰 보내주면서 응답 헤더의 Content를 알맞게 설정할 것이다. 

Accep-Charset: utf-8
Accept-Language: ko, en-US
Accept-Encoding: br, gzip, deflate

Charset은 문자 인코딩(UTF-8 등)을 명시하는 부분이고, Language는 원하는 언어, Encoding은 원하는 컨텐츠 압축 방식이다. 

뭘 적어야할지 모르겠다면 *를 적거나, 그냥 브라우저가 알아서 설정해서 보내는 Accept를 사용하면 된다.

Authorization

Authorization 헤더는 인증 토큰(JWT든, Bearer 토큰이든)을 서버로 보낼 때 사용하는 헤더이다. 

API 요청 같은 것을 할 때 토큰이 없으면 거절당하기 때문에, 이때 Authorization을 사용하면 된다. 

Authorization: Bearer XXXXXXXXXXXXX

보통 Basic이나 Bearer 같은 토큰의 종류를 먼저 알리고, 그 다음에 실제 토큰 문자를 적어 보낸다. 

Origin

POST 같은 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지를 나타낸다. 

여기서 요청을 보낸 주소와 받는 주소가 다르면 CORS 문제가 발생하기도 한다. 

Referer

이 페이지 이전의 페이지 주소가 담겨 있다. 

이 헤더를 사용하면 어떤 페이지에서 지금 페이지로 들어왔는지 알 수 있기 때문에 애널리틱스 같은 곳에 많이 사용된다. 재밌는 사실은, Referer은 오타다. Referrer가 표준어인데 실수로 Referer로 만들었다고 한다. 

다음 포스팅에서는 응답 헤더에 대해서 알아보자. 

2021.05.28 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 응답 헤더

이 포스팅은 아래 링크를 참고하였습니다. 

https://www.zerocho.com/category/HTTP/post/5b3ba2d0b3dabd001b53b9db

HTTP는 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 

(*HTTP에 대해 알고 싶다면 아래 포스팅을 읽어보세요)

https://dolphinsarah.tistory.com/38

이번 포스팅에서는 HTTP 메소드에 대해 알아보고자 한다. 

HTTP 메소드는 HTTP 요청을 할 때 사용하는 메소드이다. 

데이터를 가져오고 싶으면 GET 메소드를, 데이터를 새로 만들고 싶으면 POST 메소드를, 데이터를 삭제하고 싶으면 DELETE 메소드를, 데이터를 수정하고 싶으면 PATCH 메소드를, 이외에도 PUT, HEAD, OPTIONS, CONNECT, TRACE 등이 있다. (자주 사용되는 것은 GET, POST, DELETE, PATCH, PUT 정도이다.)

이 메소드들을 필요에 맞게 요청 시 사용하면 된다. 

요청만 보낸다고 그대로 되는 것은 아니고, 서버가 요청을 검증한 후 유효하면 실행된다. 

HTML을 배웠다면 다들 form을 한 번씩 만들어보았을텐데, 아래와 같은 HTML form에 데이터를 입력하고 새로운 form을 만들고자 할 때는 method를 POST로 설정하고, action을 명시해주어야 한다. action은 form 데이터를 서버로 보낼 때 해당 데이터가 도착할 URL이다. 

<form action="/examples/media/action_target.php" method="post">
    이름 : <input type="text" name="st_name"><br>
    학번 : <input type="text" name="st_id"><br>
    학과 : <input type="text" name="department"><br>
    <input type="submit">
</form>

HTML form만 사용해보았다면, 메소드로 GET과 POST만 사용해보았겠지만, 실제로 요청을 보낼 때는 PUT, DELETE, PATCH 등 더 자세한 동작을 정의할 수 있다. 

보통 PUT은 전체 수정(대체), PATCH는 부분 수정, DELETE는 제거 요청 시 사용한다. 

이처럼 주소를 자원이라 보고, 메서드를 동사라고 보는 개발 방식이 바로 REST이다.

예를 들어, GET /user라고 요청을 보내면, 사용자들의 정보를 가져오겠다는 의미이고, DELETE /user/5라고 요청을 보내면, id가 5인 사용자를 제거하겠다는 의미가 된다. 

GET과 DELETE를 제외한 POST, PUT, PATCH는 요청을 보낼 때 본문을 같이 보낼 수 있다.  

GET과 DELETE도 본문을 넣어 보내는 것이 불가능한 것은 아니지만, GET과 DELETE의 본문은 어떻게 처리해야 한다는 정의가 없기 때문에(서버가 본문을 무시하는 것이 권장된다고 한다), GET이나 DELETE 요청 시에는 본문을 같이 보내지 않는다. 

아래는 내가 만든 웹사이트의 회원가입 요청 시의 POST 메소드를 사용한 예다. 

Request Payload 부분이 본문 부분(헤더 다음에 들어가는 부분)이다.

서버는 저 본문을 받아 파싱(해석)한 후 사용하게 된다. 

나머지 HEAD, OPTIONS, TRACE, CONNECT에 대해서도 알아보자. 이 메소드들은 쓰는 사람들을 제외하고는 자주 보기 힘든 메서드들이다. 

HEAD는 요청에서 헤더만 가져올 때 사용한다. 단, 헤더가 GET 요청의 헤더이다. 

HEAD https://www.dolphinSarah.com HTTP/1.1 요청을 보낸다면, GET https://www.dolphinSarah.com HTTP/1.1 요청을 보내고 헤더만 가져오는 것과 동일하다는 뜻이다. 

OPTIONS는 CORS 문제에서 본 적이 있을 것이다. OPTIONS는 서버가 어떤 메서드를 지원하는지 알아볼 때 사용한다. 

아래와 같이, OPTIONS를 통해 서버가 OPTIONS, GET, HEAD, POST 메서드를 지원한다는 사실을 알 수 있다. 

또한, CORS 상황에서는 다른 도메인 서버에 먼저 OPTIONS 요청을 날린 뒤, 그 서버가 요청을 허용하면 실제 요청(GET, POST 등)을 날린다. 

즉, OPTIONS 요청은 서버에게 실제 요청을 보내기 전에 서버를 테스트하는 용도라고 보면 된다.

TRACE와 CONNECT는 진짜 쓰이는 곳에서만 쓰인다고 한다. 나는 아직까지 한 번도 써본 적은 없지만, TRACE는 핑퐁 테스트 같은 곳에 쓰이고, CONNECT는 양방향 연결을 할 때(SSL(HTTPS)을 사용하는 웹사이트에 접속할 때) 쓰인다고 한다. 

지금까지 HTTP 요청 메소드들에 대해 알아보았는데, GET, POST, DELETE, PUT, PATCH, OPTIONS 정도만 알아두면 된다. 

시작줄을 알았으니, 이제 헤더에 대해 알아보자. 

2021.05.27 - [CS/네트워크] - [네트워크] 알아두면 좋은 HTTP 공통 헤더와 요청 헤더

아래의 포스팅을 참고하여 작성하였습니다. 

https://www.zerocho.com/category/HTTP/post/5b3723477b58fc001b8f6385

HTTP는 Hyper Text Transfer Protocol로, 인터넷에서 데이터를 주고 받을 수 있는 프로토콜이다. 

(데이터를 주고 받으면서 발생하는 에러(ex) CORS, CORB)들은 HTTP만 잘 알아도 쉽게 해결할 수 있다.)

아래 이미지는 내가 만든 웹사이트의 어떤 포스트의 데이터를 가져오는 요청과 그에 대한 응답 정보를 담고 있는 헤더이다. 저 각각의 줄들이 다 정보를 담고 있다. 

서버의 역할은 요청에 대한 응답을 보내준다는 것임을 기억하며 '요청'부터 알아보자. 

요청

위 이미지에서 내 웹사이트 서버에게 localhost:3060/post/45에 대한 정보를 달라고 요청했다. 요청을 보낼 때는 요청에 대한 정보를 담아서 서버로 보낸다. 

서버도 응답할 때 응답에 대한 정보를 담아 클라이언트로 보낸다. 이런 정보가 담긴 메세지를 HTTP 메세지라고 한다. 

HTTP 메세지는 시작줄, 헤더, 본문으로 구성됩니다. 

첫 줄은 시작줄이다. POST (웹사이트 주소) HTTP/1.1이라고 적혀있다. POST는 HTTP 메서드이다. HTTP/1.1는 HTTP 버전이다. 즉, 요청 메세지의 시작줄은 메서드(POST)-주소(웹사이트 주소)-버전(HTTP/1.1)으로 구성된 것이다. 

두 번째 줄부터는 헤더이다. 요청에 대한 정보를 담고 있다. User-Agent, Upgrade-Insecure-Requests 등이 헤더에 해당된다. 헤더 종류는 이 뿐만 아니라 매우 다양하다. 

헤더에서 한 줄 띄우고 본문이 시작된다. 본문은 요청을 할 때, 함께 보낼 데이터를 담는 부분이다. 예를 들어 사용자가 회원가입 요청을 보냈을 때, 아이디, 비밀번호 등 다양한 데이터가 요청에 포함되는데, 이런 데이터가 본문에 담겨있다. 

응답

아래는 HTTP 메시지(응답)이다. 

요청과 마찬가지로 시작줄, 헤더, 본문으로 구성되어 있다. 

첫 줄은 버전(HTTP/1.1)-상태코드(403)-상태메세지(Forbidden)로 구성되어있다. 

두 번째 줄부터는 헤더이다. 응답에 대한 정보를 담고 있다. 역시 헤더 종류는 매우 다양하다. 

요청을 할 때는 따로 전송할 데이터가 없다면 본문이 없는 경우도 있지만, 응답에는 보통 본문이 있다. 보통 서버에 데이터를 요청하고, 응답 메시지에는 요청한 데이터를 담아서 보내주기 때문이다. 

이처럼 HTTP 메시지만 보아도 정말 많은 정보를 알 수가 있다. 

다음으로는 HTTP 요청 메소드에 대해 알아보겠다. (아래 포스팅을 클릭해주세요)

https://dolphinsarah.tistory.com/39

다음 글을 참고하여 작성했습니다.

https://www.zerocho.com/category/HTTP/post/5b344f3af94472001b17f2da

네트워크

여러 대의 컴퓨터가 서로 통신하기 위해 연결되면 그게 바로 네트워크!

1) 물리 계층 

(무선 혹은 유선으로)연결되어 있는 A컴퓨터에서 B컴퓨터로 데이터를 보낸다고 하자.

이때, 데이터를 전기적신호 or 광신호로 바꾸어 B컴퓨터에 전달하는 물리적 기술과 장비들을 다루는 영역을 1계층 또는 물리 계층이라고 한다. 

2) 데이터 링크 계층

이렇게 다수의 컴퓨터와 연결이 되면, 서로 다른 컴퓨터들을 구분할 필요가 있다. 

그래서 모든 통신 기기들은 서로 구분할 수 있는, 겹치지 않는, 유일한 번호인 MAC(Media Access Control)주소를 가진다. 

그래서 각 기기들이 MAC 주소로 구분되고, 서로 통신할 수 있게 된다. 

그런데, 네트워크로 연결된 컴퓨터들이 많아질수록 선이 엄청 많이 필요하게 된다. 

컴퓨터가 2대라면 단 하나의 선만 필요하지만, 3대라면 3개, 4대라면 6개,,,,,,

이러한 선의 낭비를 줄이기 위해 '허브, 스위치'라는 장치가 등장했다. 

하지만 또 이렇게 스위치로 모든 컴퓨터 선들이 연결되니, 각 컴퓨터들의 데이터들이 한 곳으로 모여 충돌하면서 여러 문제가 발생한다. (ex) 순서는 어떻게 할지, 동시에 들어오는 데이터들의 충돌은 어떻게 할지 등)

그래서 데이터 링크 계층, 2계층에서는 이런 충돌을 피하고 어떻게 효율적으로 데이터들을 연결하여 통신을 원활하게 할지에 대한 기술과 기계들을 다루는 영역이다. 

3) 네트워크 계층

위와 같이 스위치로 연결된 ABCD 네트워크와 또 다른 스위치로 연결된 A'B'C'D' 네트워크를 연결하면 ABCDA'B'C'D'라는 또 하나의 네트워크가 됩니다.  

여기까지만 보면 괜찮지만, '같은 네트워크에 속한 모든 기기'는 모르는 컴퓨터의 이름(주소)를 알아내기 위해, 연결된(같은 네트워크에 속한) 모든(broad) 컴퓨터들에게 'x 컴퓨터 주소가 뭐야?'라는 질문을 던지는(cast), 브로드캐스팅(Broadcasting, 방송)을 합니다. 

그런데, 컴퓨터든 스위치든 일정 시간이 지나면 '브로드캐스팅'으로 알아낸 주소를 까먹습니다. 그래서 일정 시간마다 다시 브로드 캐스팅을 하면서 트래픽이 계속 발생하게 됩니다. 

전 세계 모든 컴퓨터들을 2계층의 스위치로만 구성한다면, 전 세계 모든 기기들이 같은 네트워크에 속하게 될 것이고, 같은 네트워크에 속했기 때문에 모든 컴퓨터들이 특정시간마다 브로드캐스팅을 보내면, 엄청난 트래픽에 의해 네트워크가 마비될 것입니다. 

그러므로 네트워크를 나눠야 합니다. 이때, 네트워크를 나눠주는 기기가 바로 라우터입니다.

아래와 같이 네트워크와 네트워크 사이에 끼어, 네트워크를 구분하고 또 연결해줍니다. 

또한 라우터는 다른 네트워크까지의 최단 거리를 계산해서, 목적지 네트워크까지의 최단 거리를 알고 있습니다. 

위처럼 A네트워크에 속한 컴퓨터가 F네트워크에 속한 컴퓨터와 통신하려고 할 때, 1번 노랑색 길은 라우터 1개를 거쳐가고, 2번 핑크색 길은 라우터 2개를 거쳐간다. 

라우터는 다른 네트워크까지의 최단 거리를 계산할 수 있으므로, 2번 길이 아닌 1번 길로 보내는 것이 빠르다고 판단하고, 1번 방향으로 A 네트워크의 컴퓨터 패킷(네트워크 계층에서 데이터의 단위)을 F 네트워크로 보낸다는 것이다. 

이런 식으로 수많은 라우터와 라우터들이 연결되어 전 세계 모든 네트워크가 연결된 것이 바로 인터네트워크(Internetwork), 인터넷이다. 

그런데, 라우터가 어떻게 길을 찾고, 각각의 네트워크를 구분할까? 

현실에서 주소를 통해 길을 찾는 것처럼, 인터넷에서의 구분을 위한 주소가 바로 IP 주소이다. 

인터넷에선 IP 주소로 모든 것이 구분되고 통신을 하기에, 인터넷을 사용하려면 반드시 IP주소를 할당받아야 한다. 

이렇게 '네트워크와 네트워크' 사이의 통신에서 사용되는 기술과 장비를 다루는 영역이 네트워크 계층, 3계층이다. 

그리고, 당연히 네트워크 계층에도 다른 네트워크와의 통신에서 데이터의 충돌, 혼선을 빚지 않게 해주고, 목적지까지 데이터를 잘 전달하게 해 주는 기술이 당연히 있다. 

컴퓨터 공학에서 이런 기술들을 주로 '프로토콜'이라고 한다. 

네트워크 계층인 인터넷에서 네트워크들을 구분하고, 데이터를 효율적인 형태인 '패킷'으로 나눠주는 기술을 'IP(Internet Protocol)'라고 한다. 

4) 전송 계층

네트워크를 구분하고, 데이터를 패킷으로 만드는 것은 IP로 해결이 됐지만, 수~많은 라우터들이 연결되어 있는 인터넷은 특정 네트워크까지 패킷을 보내는 방법에 엄청나게 많은 경우의 수가 있다. 

그러니까 패킷들이 목적지까지 나눠져서 가다가 중간에 특정 길에 문제가 생겨 끊기면 패킷이 소실되는 일도 발생한다는 것이다. 

그래서 기기 종류와 상관없이 네트워크에 접속한 모든 기기들에게 데이터를 안전하게 전송할 수 있는 기술이 개발되었다. 그게 바로 TCP와 UDP! 

이렇게 데이터를 어떻게 목적지까지 전송할지에 대한 기술과 장비를 다루는 영역이 전송 계층, 4계층이다. 

TCP와 UDP 및 나머지 5, 6, 7계층에 대해서도 알고 싶다면 아래 포스팅을 참고해주세요.

https://dolphinsarah.tistory.com/36

OSI 참조 모델(Open Systems Interconnection reference model)

우리가 흔히 OSI 7계층이라고 부르는 것은 사실, OSI 참조 모델이다. 

국제표준화기구(ISO)에서 개발한 네트워크 모델이고, 네트워크 동작을 7계층(layer)으로 구성하여 설명하고 있다. 

OSI 참조 모델이 필요한 이유

OSI 참조 모델은 어떤 필요에 의해 만들어졌을까?

실제로 많은 물건들은 참조 모델을 바탕으로 만들어지고, 유지보수된다. 

예를 들어, 자동차에 참조 모델이 없다면, 자동차의 타이어나 엔진이 고장났을 때 자동차를 아예 바꿔야 하는 것이다.   

자동차 회사에서 자동차의 모든 것을 만드는 게 아니기 때문에 자동차 회사와 타이어 회사, 엔진 회사와의 규칙, 약속이 있어야, 자동차의 특정 부분이 고장나더라도 해당 부분만 수리해서 자동차를 계속 이용할 수 있는 것이다. 

즉, 참조 모델은 어떤 제품을 만들 때 없어서는 안될 규격이자 규칙, 약속과 같은 것이다. 

컴퓨팅 장치나 네트워킹 장치를 만들고 유지보수 할 때에도 참조 모델이 꼭 필요하고,

모든 통신장치들은 OSI 참조 모델(네트워크 모델)을 참고하여 만들어지고 유지보수된다.  

OSI 참조 모델을 통해 통신이 일어나는 과정을 단계별로 파악할 수 있고, 네트워크에서 트래픽의 흐름을 볼 수 있다. 

일반적인 네트워크의 계층 구조

OSI 참조 모델(네트워크 모델)을 알아보기 전에, 일반적인 네트워크의 계층 구조는 어떻게 되어있는지 확인해보자. 

일반적인 네트워크 계층 구조는 크게 LAN, 인터넷, 응용 프로그램으로 이루어져 있다. 

LAN

• 유선 혹은 무선으로 기기를 연결하는 계층 
• 기기 간 데이터 전송 시 속도 제어 및 오류를 검출하는 계층 

인터넷

• 네트워크와 네트워크를 연결하는 계층 
• 네트워크 간 데이터 전송 시 속도 제어 및 오류를 검출하는 계층

응용프로그램

• 계층의 최상단, 사용자가 사용하는 프로그램이 있는 계층 
• ex) 웹, 채팅, 게임

OSI 참조 모델

그럼 이제 국제 표준화 기구에서 개발한 네트워크 모델인 OSI 참조 모델에 대해 알아보자.

위의 일반적인 네트워크 계층에서 보았던 것도 보인다.

(계층 1, 2는 LAN, 계층 3,4는 인터넷, 계층 7은 응용프로그램)

그럼 이제 하나하나 OSI 참조 모델 7계층에 대해 세세하게 알아보도록 하자. 

물리 계층(Physical Layer)

네트워크에서 유선 혹은 무선으로 인접한 기기 간 연결을 담당하며, 네트워크 연결선의 특징, 무선 연결 방식의 특징을 규정한다. 

• 신호: 아날로그 신호를 사용하는 네트워크 vs 디지털 신호를 사용하는 네트워크
• 데이터를 전송하는 매체: 유선 vs 무선 

물리 계층에서 사용되는 통신 단위는 비트(0과 1)이다. 즉, 전기적으로 on/off 상태. 

이 계층에서는 단지 데이터를 전달하는 기능만 수행하고, 에러에는 관여하지 않는다. 

데이터 링크 계층(DataLink Layer)

인접한 기기 간에 오류 없는 데이터를 전송할 수 있도록 해주고, 물리 계층을 통해 데이터를 주고 받을 때 얼마나 빠른 속도로 데이터를 주고받을지, 받은 데이터에 오류가 없는지 등을 살펴본다.  

즉, 물리 계층을 통해 송수신되는 정보의 오류와 흐름을 관리하여 안전한 정보의 전달을 수행할 수 있도록 도와주는 역할을 한다. 

• IP 주소 - 인터넷으로 연결된 각 컴퓨터마다 유일하게 부여된 주소, 네트워크 계층에서 사용함 
• MAC 주소 - IP 주소 외에도 데이터 링크 계층에서 사용하는 주소, 제조사에서 통신 장비에 부여하는 고유한 주소, 물리적 주소라고도 함(데이터가 LAN에서만 움직일 때는 MAC 주소를 사용하고, LAN을 빠져나와 인터넷을 돌아다닐 때는 IP 주소를 사용)
• CRC 코드 - 오류 탐색 코드

데이터 링크 계층에서의 데이터 단위는 프레임이다. 

네트워크 계층(Network Layer)

LAN들을 연결하여 인터넷을 구성하는 계층이다.

LAN들 사이에서 데이터를 어떻게 주고 받을지 결정하며, 어떤 경로로 데이터를 보낼지도 결정한다. 

(경로를 선택하고, 경로에 따라 패킷을 전달해줌) 

• 패킷 - 네트워크 계층에서 데이터의 단위
• 라우팅 - 어떤 경로로 패킷을 보낼지 결정하는 것 (경로배정), 네트워크 계층에서 가장 중요한 기능(데이터를 목적지까지 가장 안전하고 빠르게 전달해야 함)
• 라우터 - LAN과 LAN을 연결하는 기계, 데이터를 한쪽 네트워크에서 다른 쪽 네트워크로 전달하는 기기
• IP(Internet Protocol) - 인터넷에서 패킷 전송을 담당하는 프로토콜, 주요 역할은 라우팅(뒤바뀌거나 사라진 패킷을 원래대로 맞추어주는 일을 전송 계층에 있는 TCP가 수행, 인터넷을 사용할 때 TCP/IP를 같이 사용)
• IP 주소 - 통신을 하려면 주소가 필요, 인터넷으로 연결된 각 컴퓨터마다 유일하게 부여된 주소, 이 주소는 라우팅할 때 가장 중요
• 도메인 이름 - 인터넷에서 통신하려면 IP 주소가 꼭 필요하지만 사람이 외우기 힘드므로, IP 주소에 이름을 붙여주는 것 
• DNS(Domain Name Service) - 도메인 이름을 IP 주소로 바꾸어주는 것, 사용자가 웹 브라우저에 도메인 이름을 쓰면 웹 브라우저는 DNS 서버(도메인 이름과 IP 주소를 모아 놓은 컴퓨터)에 접속하여 IP 주소를 받아옴

전송 계층(Transport Layer)

전송 계층을 통해 양 끝단의 사용자들이 신뢰성 있는 데이터를 주고 받을 수 있다. 

출발지에서 목적지 컴퓨터끼리 데이터를 주고받을 때 오류를 점검하고 보정하며, 오류가 있으면 재전송 요청을 한다. 

네트워크 계층의 'IP'만으로도 데이터를 목적지까지 전달할 수는 있지만, 중간에 데이터가 손상되거나 유실되었을 때의 방법이 없다.

데이터의 확실한 전송을 위해 전송계층에서 'IP'와 (TCP or UDP)를 함께 사용하면 데이터가 중간에 손상되거나 유실되었을 때 다시 보낼 수 있다. 

◆ TCP(Transmission Control Protocol)

정확한 데이터를 전송하는 것이 목적이다. ex) 택배원이 직접 우리 집에 찾아와 내 사인을 받고 택배물을 나에게 전달해주는 것

3-way-handsahke

: 'TCP' 통신은 데이터를 전송하기 전에 3가지의 확인 과정을 거친 후에 데이터를 전송한다. 택배원이 우리집(IP)으로 찾아와 문을 두들기고(요청) 내가 (대답) 후, 누구냐고 물어보면(요청), 택배원이 '택배입니다' (대답)하면서 3번 서로의 안전을 확인한 후, 택배(데이터)를 받게 된다. 3-way-handshake로 인해 시간은 다소 걸리지만, 데이터 복구 기능이 있어 데이터를 안전하게 받을 수 있다는 장점이 있다. 

◆ UDP(User Datagram Protocol)

정확한 데이터 배달보다는 빠른 전송이 목적이다.  ex) 택배원이 모든 택배물을 경비실에 두고 가는 것

TCP와는 달리 UDP는 스위치(라우터)의 브로드캐스트 주소(경비실)에 그냥 데이터(택배)를 보내버린다. 그러면 컴퓨터는 UDP 브로드캐스트를 받아본 다음 자신에게 온 것이면 받고, 아니면 무시한다. 이런 경우 실제와 마찬가지고, 택배(데이터)가 유실되거나 도둑맞아도 택배원은 책임이 없다. 

UDP를 사용하면, 3- way-handshake가 필요한 TCP와 비교해 매우매우 빠른 통신이 가능하지만, 데이터가 제대로 목적지에 전달되었는지 보장할 수 없어 안전성이 낮다. 

신뢰성과 안정성이 중요한 작업이라면 TCP 통신을 하고, 동영상과 같이 빠른 데이터의 전송이 필요한 작업이라면 UDP 통신을 사용한다. 

◆ 포트 번호(Port)

더 효율적인 통신을 위해 사용하는 '전송 계층'의 기술은 포트 번호(Port)이다. 

포트 번호는 컴퓨터의 어느 애플리케이션(응용프로그램)에게 데이터를 전달할지 알려주는 번호이다. 

IP 주소가 아파트의 동번호라면, Port 번호는 아파트의 호수라고 생각하면 된다. 

즉, 특정 컴퓨터의 어떤 애플리케이션에게 데이터를 전달하라고 추가적으로 적는 번호가 바로 포트 번호인 것이다. 

이렇게 전송 계층에서 목적지 애플리케이션 '포트번호'와 '데이터들의 순서'를 적고 'TCP or UDP'를 써서 만든 데이터의 형태를 세그먼트라고 한다. 

세션 계층(Session Layer) 

'네트워크 계층의 IP'를 통해 컴퓨터를 찾아가고, '전송 계층의 포트 번호'를 이용해 컴퓨터의 애플리케이션을 찾아가고, '전송 계층의 TCP or UDP'로 안전한/빠른 연결을 확인하였다.  

그러고 나면 서버의 애플리케이션과 클라이언트의 애플리케이션 사이에 데이터 전송을 위한 논리적인 연결통로가 생긴다. 

이 때, 실시간으로 데이터를 주고 받기 위한 두 컴퓨터의 논리적 연결, 만남을 세션(Session)이라 하고, 이런 세션을 만들고, 유지, 종료할 때 사용되는 기술과 장비들을 '세션 계층'이라고 한다. 

표현 계층(Presentation Layer) 

세션이 만들어지고, 데이터를 전송하려고 하는데, 각 애플리케이션마다 사용하는 데이터 형태가 다르다. 

그래서 세션을 통해 넘어오는 데이터들을 애플리케이션에서 필요한 형태로 변환(데이터를 어떻게 변환할지 다루는 계층)해 애플리케이션에서 표현하는 계층이기 때문에 '표현 계층'이라고 한다. 

데이터를 암호화하는 계층이고, 웹에서 흐르는 데이터를 암호화하려면 반드시 표현 계층을 거쳐야 한다. 

응용 계층(Application Layer)

우리가 사용하는 사용자 인터페이스를 제공하는 응용 프로그램들의 상호작용을 다루는 계층이다. 

세상에 정말 수없이 많은 응용프로그램이 있듯, 각 응용 프로그램에 사용하는 수많은 프로토콜이 있다. 

대표적으로 인터넷상에서 문자(Hyper Text) 데이터를 다루는 프로토콜 HTTP, 파일을 주고 받을 때 사용하는 프로토콜 FTP, 도메인 네임서버를 찾을 때 사용하는 프로토콜 DNS, SSH 연결을 할 때 사용하는 프로토콜 SSH 등이 있다.