[CS] 네트워크

프로토콜

컴퓨터 간 데이터 통신을 원활하게 하기 위해 정해놓은 약속

 

HTTP(Hypertext Transfer Protocol)

하이퍼텍스트를 전송하는 규약을 의미한다. 하이퍼텍스트는 한 문서에서 다른 문서로 이동할 수 있는 하이퍼링크를 가진 문서를 말한다. 여기서 텍스트는 HTML이다. 비연결성 프로토콜이다. 요청(request)에 대한 응답(response)만 전달되며 연결이 유지되지 않는다. 상태도 유지하지 않는다(stateless).  비연결성을 해결하기 위해 쿠키와 세션이 사용된다.

 

쿠키

클라이언트(사용자)에서 저장하고 있는 서버의 정보다. 쇼핑몰의 장바구니, 자동로그인 팝업 체크 등의 정보를 쿠키를 통해 저장한다. 브라우저가 종료되도 쿠키는 별도의 만료시간에 따라 삭제된다. 로컬에 저장되는 만큼 보안에 취약하다.

 

세션

서버에서 저장하고 있는 클라이언트의 정보다. 서버는 클라이언트를 식별하기 위해 세션 아이디를 사용한다. 브라우저가 종료되면 세션은 사라진다. 서버에 있으므로 쿠키보다 상대적으로 안전하다.

 

HTTPS(Hypertext Transfer Protocol over Secure Socket Layer or TLS)

HTTPS는 SSL 프로토콜 위에서 돌아가는 프로토콜이다. SSL는 넷스케이프가 만들었고 표준화기구를 통해 TLS(Transport Layer Security)로 바뀌었지만 SSL이라는 이름이 더 많이 사용된다. SSL은 대칭키와 공개키라는 두 가지 암호화 방식을 혼용해서 사용한다.

 

대칭키

동일한 키로 암호화와 복호화를 진행한다. 비교적 속도가 빠르다. 발송인과 수신인이 상호작용하려면 서로 같은 키를 갖고 있어야 한다. 대칭키를 전달하는 과정에서 유출될 수 있다.

 

공개키

암호화와 복호화에 다른 키를 사용한다. 공개키로 암호화하면 개인키로, 개인키로 암호화하면 공개키로 복호화할 수 있다. 수신자의 공개키로 내 메시지를 암호화하면 중간에 가로채더라도 복호화할 수 없다. 복호화하는 수신자가 갖고 있는 개인키로만 가능하기 때문이다. 다른 키로 암호화, 복호화가 이뤄지기 때문에 연산에 비교적 시간이 많이 든다.

 

1. HTTPS를 위해 사이트는 인증기관(CA)에 사이트의 정보와 공개키를 제출한다.

2. 인증기관은 사이트의 정보와 공개키를 자신의 개인키로 암호화하여 사이트의 인증서를 제작한다.

3. 인증기관은 사이트에 인증서를 발급한다.

4. 인증기관은 웹 브라우저에게 공개키를 제공하고 브라우저는 해당 공개키를 내장한다.

 

5. 브라우저가 사이트에 접속을 요청하면 사이트는 인증기관으로부터 발급받은 인증서를 브라우저에 전달한다.

6. 브라우저는 내장된 공개키를 이용해 인증기관의 개인키로 암호화된 인증서를 검증한다.

7. 브라우저는 인증서 검증이 완료되면 사이트의 정보와 공개키를 얻는다.

8. 브라우저는 획득한 사이트의 공개키를 이용해, 임시 무작위으로 생성한 대칭키를 암호화해 사이트로 전송한다.

9. 사이트는 개인키로 복호화하여 브라우저의 대칭키를 얻는다.

10. 브라우저와 사이트는 안전하게 전달된 대칭키를 이용해 암호문을 주고 받는다.

 

URI(Uniform Resource Identifier) vs URL(... Locator)

URI는 URL의 상위개념이다. 모든 URL은 URI이지만, URI라고 해서 URL인 것은 아니다. URI에는 URN도 있기 때문이다. URN은 Uniform Resource Name의 두음문자어로 urn:으로 시작하며 이름으로 자원을 식별하는 것을 말한다.

• urn:isbn:0451450523 to identify a book by its ISBN number.
• urn:uuid:6e8bc430-9c3a-11d9-9669-0800200c9a66 a globally unique identifier
• urn:publishing:book - An XML namespace that identifies the document as a type of book

웹에서 혼용되는 용어는 대부분 URI와 URL이다. 앞서 말했듯 URI는 URL의 상위 개념이기 때문에 URL이라고 표현하는 것이 더 정확하다. 지나가는 고양이를 보고 "동물이네"이라고 하는 것보다 "고양이"이라고 말하는 것이 더 정확하다. URL에서 L은 locator이기 때문에 URL은 자원의 위치를 알려주는 식별자다.

• http://example.com/mypage.html
• ftp://example.com/download.zip
• mailto:user@example.com
• file:///home/user/file.txt
• http://example.com/resource?foo=bar#fragment

현대 사이트 주소의 대부분은 URL 그대로 자원 위치라고 말하기 어렵다. 보통 스프링을 통해, 해당 주소에 맵핑되는 클래스 함수를 호출해 자원을 획득하기 때문이다. URL을 통해 자원을 획득하는 개념은 옛날과 다르지 않다.

 

웹 동작 방식

③ 사용자가 입력한 URL 주소 중에서 도메인 네임(domain name) 부분을 DNS 서버에서 검색

④ DNS 서버에서 해당 도메인 네임에 해당하는 IP 주소를 찾아 사용자가 입력한 URL 정보와 함께 전달

⑤⑥ HTTP 프로토콜을 사용해, 웹 페이지 URL 정보와 전달받은 IP 주소를 HTTP 요청 메시지로 생성

    - HTTP 요청 메시지는 TCP를 사용해 IP 주소의 컴퓨터로 전송

⑦ 도착한 HTTP 요청 메시지는 HTTP 프로토콜을 사용하여 웹 페이지 URL 정보로 변환

⑧ 웹 서버는 도착한 웹 페이지 URL 정보에 해당하는 데이터를 검색

⑨⑩ 검색된 웹 페이지 데이터는 또 다시 HTTP를 사용해 HTTP 응답 메시지를 생성

    - HTTP 응답 메시지는 TCP를 사용해 인터넷을 거쳐 원래 컴퓨터로 전송

⑪ 도착한 HTTP 응답 메시지는 HTTP를 통해 웹 페이지 데이터로 변환

⑫ 웹 브라우저가 변환된 웹 페이지 데이터를 출력하면 사용자가 볼 수 있음

 

다른 표현

브라우저 주소창에 http://www.test.com 입력 후 엔터를 눌렀을 때부터 페이지가 렌더링 되는 과정
1) local DNS(가장 가까운) → 루트 DNS 서버 → .com DNS 서버 → test.com DNS 서버 순서대로 www.test.com에 해당하는 IP주소 요청하고, 있다면 그 서버에서 바로 주소를 받음(조회하는 정보가 캐시에 있으면 더 빨리 회답받을 수 있음)

2) TCP 통신을 통해 소켓 개방
3) HTTP 프로토콜로 요청
4) 라우팅 중 프록시 서버를 만나면 웹 캐시에 저장된 정보로 응답받음(프록시 서버는 요청받은 내용을 캐시에 저장)
5) 프록시 서버를 만나지 못하면 www.test.com를 운용하는 서버까지 가서, 요청에 맞는 데이터를 응답 받음
6) 브라우저의 로더가 해당 응답을 다운로드
7) 브라우저의 웹 엔진이 다운로드한 .html 파일을 파싱해 DOM 트리를 결정
8) .html 파싱 중 스크립트 태그를 만나면 파싱을 중단함
9) 스크립트 태그에 있는 자원을 다운로드해 처리가 완료되면 다시 파싱을 이어감
10) CSS parser가 .css 파일을 파싱해 스타일 규칙을 DOM 트리에 추가하고 렌더 트리를 생성
11) 렌더 트리를 기반으로 브라우저의 크기에 따라 각 노드들의 크기를 결정
12) 렌더링 엔진이 배치를 시작(페인팅)

 

OSI 7계층

OSI 모형이라고도 한다. Open Systems Interconnection Reference Model. 네트워크에서 통신이 일어나는 과정을 상하 구조를 갖는 7계층으로 나눈 것

 

목적

통신이 일어나는 과정을 단계별로 나누어 놓으면 문제가 생겼을 때 원인을 파악하기 용이하다. 네트워크는 장비가 많기 때문에 원인을 명확하게 알게 되면 살펴볼 장비가 제한돼 유지보수에 좋다

 

 

1계층(물리 계층, Physical layer)

케이블, 리피터, 허브 등을 통해 전기적으로 데이터를 송수신한다. 데이터의 종류, 에러 등은 관심사항이 아니다.

 

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

물리 계층을 통해 송수신되는 정보의 흐름과 오류를 관리해 정보의 전달을 수행. 맥 어드레스(랜카드의 물리적인 주소)를 가지고 통신한다. 이 계층에서 전송되는 단위를 프레임이라고 한다. 프레임에 주소를 부여한다. CRC 기반으로 오류와 흐름을 제어한다. 데이터 링크 계층이 가장 잘 알려진 예는 이더넷이다. 이더넷은 LAN, MAN, WAN에서 가장 많이 활용되는 기술 규격이다.

 

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

데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능(라우팅)을 맡는다. 경로를 선택하고 주소를 정하고 경로에 따라 패킷을 전달해준다. 네트워크 연결을 설정, 유지, 해제한다. 대표적인 장비는 라우터.

 

IP 계층

TCP/IP에서 IP 계층은 네트워크의 주소(IP 주소)를 정의하고 IP 패킷의 전달 및 라우팅을 담당하는 계층. OSI 계층에서는 3계층인 네트워크 계층에 해당한다. 즉, 패킷을 목적지까지 전달하는 역할.

 

4계층(전송 계층, Transport layer)

통신을 활성화하기 위한 계층. 보통 TCP를 사용한다. 포트를 열어 응용프로그램이 데이터를 전송할 수 있게 한다. TCP를 이용하면 연결 기반이며 신뢰성 있는 데이터 송수신을 보장한다. 전송 실패한 패킷은 재전송을 요청한다.

 

5계층(세션 계층, Session layer)

데이터가 통신하기 위한 논리적인 연결. 5계층은 TCP/IP 세션을 생성하고 해제하는 책임이 있다. 세션 설정, 유지, 종료, 전송 중단 시 복구 등의 기능이 있다.

 

6계층(표현 계층, Presentation layer)

응용 계층에서 전달받은 데이터를 읽을 수 있는 형식으로 변환한다. 응용 계층의 부담을 덜어준다. 응용 계층으로부터 전송받은 데이터를 디코딩하고 응용 계층으로 전달해야 하는 데이터를 인코딩하는 것이 이 계층.

 

7계층(응용 계층, Application layer)

응용 프로세스와 직접 관계하여 응용 서비스를 수행한다. 텔넷, 크롬, 이메일 등이다. HTTP, FTP, SMTP 같은 프로토콜이 여기에 해당된다.

 

TCP/IP 프로토콜

인터넷 프로토콜 스위트(영어: Internet Protocol Suite)는 인터넷에서 컴퓨터들이 서로 정보를 주고받는 데 쓰이는 통신규약(프로토콜)의 모음이다. 인터넷 프로토콜 슈트 중 TCP와 IP가 가장 많이 쓰이기 때문에 TCP/IP 프로토콜 슈트라고도 불린다.

 

TCP와 IP

Transmission Control Protocol / Internet Protocol

TCP/IP는 패킷 통신 방식의 인터넷 프로토콜인 IP와 전송 조절 프로토콜인 TCP로 이루어져 있다. IP는 패킷 전달 여부를 보증하고 않아 패킷을 보낸 순서와 받는 순서가 다를 수 있다. TCP는 IP 위에서 동작하는 프로토콜로 데이터의 전달 순서를 보증한다. HTTP, FTP, SMTP 등 TCP를 기반으로 하는 애플리케이션 프로토콜이 IP위에서 동작하기 때문에 묶어서 TCP/IP로 부르기도 한다.

 

TCP와 UDP

TCP/IP 프로토콜 슈트에서 전송 계층에 해당한다. OSI 7계층에서도 전송 계층에 해당한다.

 

TCP(Transmission Control Protocol)

연결형 서비스

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

1. 먼저 open()을 실행한 클라이언트가 SYN을 보내고 SYN_SENT 상태로 대기한다.
2. 서버는 SYN_RCVD 상태로 바꾸고 SYN과 응답 ACK를 보낸다.
3. SYN과 응답 ACK을 받은 클라이언트는 ESTABLISHED 상태로 변경하고 서버에게 응답 ACK를 보낸다.
4. 응답 ACK를 받은 서버는 ESTABLISHED 상태로 변경한다.

 

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

1. 먼저 close()를 실행한 클라이언트가 FIN을 보내고 FIN_WAIT1 상태로 대기한다.
2. 서버는 CLOSE_WAIT으로 바꾸고 응답 ACK를 전달한다. 동시에 해당 포트에 연결되어 있는 어플리케이션에게 close()를 요청한다.
3. ACK를 받은 클라이언트는 상태를 FIN_WAIT2로 변경한다.
4. close() 요청을 받은 서버 어플리케이션은 종료 프로세스를 진행하고 FIN을 클라이언트에 보내 LAST_ACK 상태로 바꾼다.
5. FIN을 받은 클라이언트는 ACK를 서버에 다시 전송하고 TIME_WAIT으로 상태를 바꾼다. TIME_WAIT에서 일정 시간이 지나면 CLOSED된다. ACK를 받은 서버도 포트를 CLOSED로 닫는다.

마음대로 연결을 끊어버리면 데이터 송수신의 신뢰성을 보장받지 못하게 된다. TCP의 장점인 높은 신뢰성을 유지하기 위해 클라이언트와 서버 간에 확인 절차는 거치는 것.

 

가상회선

물리적으로 전용회선이 연결되어 있는 것처럼 논리적으로 동작

 

흐름 제어

데이터 처리 속도를 조절해 수신 버퍼의 오버플로우를 방지한다.

 

혼잡 제어

네트워크 내의 패킷 수가 넘치지 않도로 방지

 

신뢰성 높은 전송

정상적인 상황에서는 ACK값이 연속적이어야 한다. 패킷에 번호를 부여하므로 전송 실패, 중복 전송을 방지한다.

 

A->B

SYN:1000 (패킷에 1000이라는 번호를 부여)

ACK: -

B->A

SYN:2000

ACK: 1001(1000 패킷 잘 받았고 다음에는 1001로 보내라)

 

전이중(Full duplex), 점대점 방식(point to point)

전이중

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

 

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

 

사용되는 곳

HTTP, FTP, SMTP 등 신뢰성 있는 데이터 송수신이 필요한 곳

 

UDP(User Datagram Protocol)

비연결형 프로토콜이므로 가성회선을 만들지 않고 연결을 수립하는 과정이 없다.

데이터의 연결을 구분하지 않는 TCP와 다르게, 경계를 구분한다

데이터 송수신의 신뢰를 보장하지 않는다. 일단 보낸다. 그냥 보낸다.

체크섬(checksum, 검사합)을 이용한 오류검사만 진행한다. 그 외에는 오류 검출 및 제어가 없다.

UDP를 사용하는 프로그램에서 오류 제어 기능을 만들어야 한다.

빠른 요청과 응답이 필요한 애플리케이션에 사용된다(+ 실시간).

헤더는 고정 크기의 8바이트(TCP는 최소 20바이트).

일대일 통신인 TCP와 달리, 브로스캐스트와 멀티캐스트도 지원한다.

 

사용되는 곳

게임, 스트리밍 등의 성능(속도) 위주의 실시간 서비스

 

브로드캐스트

로컬 랜에 붙어 있는 모든 네트워크 장비들에 보내는 통신. 패킷, 프레임을 받는 PC의 맥어드레스 주소가 실제 프레임에 적혀 있는 맥 어드레스 일치하지 않더라도 CPU에게 인터럽트를 걸고 우선적으로 받은 패킷을 처리하게 한다. CPU의 성능 저하를 초래한다.

 

멀티캐스트

전체가 아니라 특정 그룹에게 데이터를 전송할 수 있다. 200명 중 150명이라면 유니캐스트로 150명에게 150번씩 보내면 서버에 과부하가 걸릴 수 있다. 브로드캐스트로 하면 보내지 않아도 될 50명에게 불필요한 데이터를 전송하게 된다. 멀티캐스트는 라우터와 스위치가 멀티캐스트를 지원해야 가능하다.

GET과 POST

GET

HTTP/1.1 스펙인 RFC2616의 Section9.3에 따르면 GET은 서버로부터 정보를 조회하기 위해 설계된 메소드다.
GET은 요청을 전송할 때 필요한 데이터를 Body에 담지 않고, 쿼리스트링을 통해 전송한다. URL의 끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터를 쿼리스트링이라고 부른다. 만약, 요청 파라미터가 여러 개면 &로 연결한다. 쿼리스트링을 사용하면 URL에 조회 조건을 표시하기 때문에 특정 페이지를 링크하거나 북마크할 수 있다. HTTP에서는 정보가 노출될 수 있지만 HTTPS에서는 암호화되어 정보가 노출되지 않는다. 쿼리스트링을 포함한 URL 샘플은 아래와 같다. 여기서 요청 파라미터명은 name1, name2이고, 각각의 파라미터는 value1, value2라는 값으로 서버에 요청을 보내게 된다.

www.example-url.com/resources?name1=value1&name2=value2

GET은 불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다. js, css, 이미지 같은 정적 컨텐츠는 데이터양이 크고, 변경될 일이 적어서 반복해서 동일한 요청을 보낼 필요가 없다. 정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시해두고, 동일한 요청이 발생할 때 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다. 그래서 프론트엔드 개발을 하다보면 정적 컨텐츠가 캐시돼 컨텐츠를 변경해도 내용이 바뀌지 않는 경우가 종종 발생한다. 이 때는 브라우저의 캐시를 지워주면 다시 컨텐츠를 조회하기 위해 서버로 요청을 보내게 된다.

 

POST

POST는 리소스를 생성/변경하기 위해 설계되었기 때문에 GET과 달리 전송해야될 데이터를 HTTP 메세지의 Body에 담아서 전송한다. HTTP 메시지의 Body는 길이의 제한없이 데이터를 전송할 수 있다. 그래서 POST 요청은 GET과 달리 대용량 데이터를 전송할 수 있다. POST는 데이터가 Body로 전송되고 내용이 눈에 보이지 않아 GET보다 보안적인 면에서 안전하다고 생각할 수 있지만, POST 요청도 크롬 개발자 도구, Fiddler와 같은 툴로 요청 내용을 확인할 수 있기 때문에 민감한 데이터의 경우에는 반드시 암호화해 전송해야 한다. POST로 요청을 보낼 때는 요청 헤더의 Content-Type에 요청 데이터의 타입을 표시해야 한다. 데이터 타입을 표시하지 않으면 서버는 내용이나 URL에 포함된 리소스의 확장자명 등으로 데이터 타입을 유추한다. 알 수 없는 경우에는 application/octet-stream로 요청을 처리한다.

GET과 POST의 차이

GET은 Idempotent, POST는 Non-idempotent하게 설계됐다.
Idempotent(멱등)은 수학적 개념으로 다음과 같습니다.

수학이나 전산학에서 연산의 한 성질을 나타내는 것으로, 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질

멱등은 동일한 연산을 여러 번 수행하면 동일한 결과가 나타나는 것을 말한다. 여기서 GET이 Idempotent하도록 설계되었다는 것은 GET으로 서버에게 동일한 요청을 여러 번 전송하더라도 동일한 응답이 돌아와야 한다는 것을 의미한다. 이에 따라 GET은 설계원칙에 따라 서버의 데이터나 상태를 변경시키지 않아야 Idempotent하기 때문에 주로 조회를 할 때에 사용해야 한다. 예를 들어, 브라우저에서 웹페이지를 열어보거나 게시글을 읽는 등 조회를 하는 행위는 GET으로 요청하면 된다.

 

반대로 POST는 Non-idempotent하기 때문에 서버에게 동일한 요청을 여러 번 전송해도 응답이 다를 수 있다. 이에 따라 POST는 서버의 상태나 데이터를 변경시킬 때 사용된다. 게시글을 쓰면 서버에 게시글이 저장이 되고, 게시글을 삭제하면 해당 데이터가 없어지는 등 POST로 요청을 하게 되면 서버의 무언가는 변경된다. 이처럼 POST는 생성, 수정, 삭제에 사용할 수 있지만, 생성에는 POST, 수정은 PUT 또는 PATCH, 삭제는 DELETE가 더 용도에 맞는 메소드라고 할 수 있다.

 

출처

https://bit.ly/3bwrpp2

https://hyonee.tistory.com/136

https://shlee0882.tistory.com/110

https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/