[Network][2주차] 네트워크 서비스와 애플리케이션 계층

케이·2022년 8월 14일
0

네트워크 스터디

목록 보기
2/6
post-thumbnail

'TCP/IP 쉽게 더 쉽게' 라는 책을 중심으로 학습 정리한 포스팅입니다. 잘못된 내용이 있다면 언제든 지적해주시면 감사하겠습니다.🙇🏻‍♀️

애플리케이션 계층

애플리케이션 계층은 사용자가 직접 사용하면서 체감할 수 있는 서비스를 제공한다. 애플리케이션 계층보다 하위에 있는 계층들은 데이터 전송(컴퓨터간의 통신)을 담당한다.

  • 사용자가 직접 사용하는 프로토콜
    • HTTP: 웹 클라이언트와 웹 서버 사이에서 웹 페이지 데이터를 주고 받는다
    • POP, SMTP, IMAP: 메일을 송수신하고 보관한다
    • SMB, AFP: LAN안에서 파일을 공유한다
    • FTP: 서버를 통해 파일을 주고 받는다
    • Telnet, SSH: 원격에서 서버를 제어한다
  • 사용자가 간접적으로 사용하는 프로토콜
    • DNS: 도메인명과 IP어드레스 정보를 서로 변환할 때 사용한다
    • DHCP: LAN 내의 컴퓨터에게 IP어드레스를 할당할 때 사용한다
    • SSL/TLS: 통신 데이터를 암호화하여 주요 정보를 안전하게 주고받을 때 사용한다
    • NTP: 네트워크에 연결된 장비들의 시스템 시간을 동기화 할 때 사용한다.
    • LDAP: 네트워크에 연결된 자원(사용자, 장비들)의 통합 관리에 필요한 디렉터리 서비스를 제공할 때 사용한다.

아래에서는 사용자가 직접 사용하는 프로토콜 중심으로 알아보고자 한다.

HTTP

웹 브라우저가 웹 서버로 특정 웹페이지를 요청하면 웹 서버가 해당 페이지의 내용을 Html 형식으로 응답한다.

HTTP 메시지

웹 브라우저와 웹 서버는 HTTP(HyperText Transfer Protocol)라는 애플리케이션 계층의 프로토콜을 사용한다. 통신 과정에서 주고받은 정보들은 HTTP 메시지라고 부르고 요청과 응답의 두 가지 형태로 구분된다.

HTTP는 상태가 없다.

통신 시 정보를 한번씩 주고 받은 후 바로 끊는 형태로 처리된다. 이를 stateless라고 하고 HTTP는 대표적인 무상태 프로토콜이다. 이는 많은 데이터를 빠르고 확실하게 처리하는 범위성(scalability)를 확보하기 위해서 간단하게 설계되어 있기 때문이다.

https://velog.velcdn.com/images%2Fdenmark-choco%2Fpost%2F9d52f8b8-e9eb-4439-a0f9-eb54d9458eca%2Fstateless.png

(출처: https://velog.io/@denmark-choco/HTTP-웹-기본-지식)

지속 연결

HTTP 초기 버전에서는 HTTP 통신을 한번 할 때마다 TCP에 의해 연결과 종료를 할 필요가 있었고 이런 기능이 문제가 없었으나 전송 문서의 크기가 커지면서(많은 이미지 등) 다량의 통신이 발생하게 되었다.

이에 HTTP/1.1과 HTTP/1.0에서는 TCP 연결 문제를 해결하기 위해서 지속 연결(persistent connections)라는 방법을 고안했다.

지속 연결은 어느 한 쪽이 명시적으로 연결을 종료하지 않는 이상 TCP을 계속 유지한다. 이를 통해 TCP 커넥션의 연결과 종료를 반복하는 오버헤드를 줄일 수 있고 서버에 대한 부하가 줄어들게 된다. 또한 오버헤드를 줄인 만큼 요청과 응답이 빠르게 완료되기 때문에 웹 페이지를 빨리 표시할 수 있다.

지속 연결은 HTTP/1.1에서는 표준동작이지만 HTTP/1.0에서는 정식 사양이 아니었다.

지속 연결을 여러 리퀘스트를 보낼 수 있도록 파이프라인화를 가능하게 한다. 이를 통해 리스폰스를 기다리지 않고 바로 다음 리퀘스트를 보낼 수 있다.

브라우저에서 양방향 통신을 하는 WebSocket

Ajax와 Comet을 사용한 통신은 웹 브라우징을 고속화 하지만 HTTP 프로토콜을 사용하는 이상 병목 현상을 해결할 수 없다. WebSocket은 이 문제를 해결하기 위한 기술이다

WebSocket은 웹 브라우저와 웹 서버의 양방향 통신 규격으로 WebSocket 프로토콜을 IETF가 책정하고 WebSocket API를 W3C가 책정하고 있다.

WebSocket은 웹 서버와 클라이언트가 한번 접속을 하고나면 그 뒤의 통신을 모두 전용 프로토콜로 하는 방식으로 JSON이나 XML, HTML 이미지 등의 임의 형식 데이터를 보내게 된다.

WebSocket 프로토콜의 주요 특징

  • 서버 푸시 기능
    • 서버는 클라이언트의 리퀘스트를 기다리지 않고 데이터를 보낼 수 있다
  • 통신량의 삭감
    • WebSocket은 접속을 한번 하면 그 이 후에도 접속을 유지한다. HTTP에 비해 오버헤드가 적어지고 헤더의 사이즈도 작아서 통신량을 줄일 수 있다.
  • 핸드쉐이크/리퀘스트
    • WebSocket으로 통신을 하려면 HTTP의 Upgrade 헤더 필드를 사용해서 프로토콜을 변경하는 것으로 핸드쉐이크를 한다. Sec-WebSocket-Key에는 핸드쉐이크에 필요한 키, Set-WebSocket-Protocol에는 사용하는 서브 프로토콜이 저장되어 있다.
  • 핸드쉐이크/리스폰스
    • 앞의 리퀘스트에 대한 리스폰스는 상태코드 [101 Switching Protocol]. Sec-WebSocket-Accept에 Sec-WebSocket-Key의 값에서 생성된 값이 저장된다. 커넥션이 확립된 후에는 WebSocket 독자적인 데이터 프레임을 이용해 통신을 한다.

HTTP요청과 URL

HTTP 요청을 보낼 때 URL(Uniform Resource Locator)라는 문자열을 사용한다.

https://media.geeksforgeeks.org/wp-content/uploads/20210625160610/urldiag.PNG

(path 안에 디렉터리 포함)

이미지 출처: https://media.geeksforgeeks.org/wp-content/uploads/20210625160610/urldiag.PNG

HTTP 응답과 상태 코드

HTTP 응답 데이터의 첫번째 행에는 요청에 대한 응답 상태를 표시하기 위한 상태코드가 들어간다.

아래의 예시에선 첫번째 줄 (status line)에서 200이 상태 코드가 됨.

https://img1.daumcdn.net/thumb/R1280x0/?scode=mtistory2&fname=https%3A%2F%2Fblog.kakaocdn.net%2Fdn%2FbkBRZH%2FbtqVV2JEnFj%2FpFjfpwMOjGI2lCLIyf6dkk%2Fimg.png

상태코드의 의미는 크게 다섯개로 나누어 볼 수 있다.

https://www.lambdatest.com/blog/wp-content/uploads/2022/07/Classes-of-HTTP-Response-Status-Codes-1.png


웹 서비스와 웹 애플리케이션

웹 서비스를 요청하면 웹 서버가 결과를 미리 만들어 놓지 않고 서버 프로그램이 HTML 데이터를 동적으로 만들어서 응답한다.
GET, POST, PUT, DELETE 등 여러 방식이 있지만 가장 많이 사용되는 GET과 POST를 정말정말 간단하게 정리해보았다.

GET & POST

HTML 입력 폼을 통해 요청을 보낼 때 주로 GET 방식과 POST 방식을 많이 사용한다.
GET 방식은 URL에 입력 폼의 내용이 포함되어 있다. → 입력 내용이 요청행에 포함된다.
POST 방식은 입력 폼의 내용이 메시지 바디에 포함된다. GET 방식보다 상대적으로 더 많은 데이터를 전송할 수 있다.


쿠키

HTTP는 무상태 프로토콜이기 때문에 요청과 응답을 한번씩 주고받은 후에 통신이 끊어진다. 여러 단계의 흐름 처리를 해야할 때는 각 요청이 동일한 사용자가 보낸 것인지 판단할 수 없기 때문에 여러 건의 요청 처리를 동일한 사용자 접속 세션으로 인식할 수 있도록 쿠키를 사용한다.

쿠키의 사용

웹 브라우저는 Response에 ‘Set-Cookie’ 라는 문자열이 있는지 확인하고 만약 있으면 그 내용을 로컬 디스크에 쿠키 형태로 저장한다. 쿠키는 악용될 경우 보안 문제가 발생할 수 있기 때문에 조치가 필요하다. (예시로 유효기간이 지난 것은 자동으로 폐기하거나 쿠키가 생성 된 웹 서버와 동일한 도메인을 사용하는 웹 사이트에서만 쿠키가 전송되도록 제한하거나)

또한 유출 시 보안 문제가 생길 만한 정보를 저장하지 않는 것이 중요해서 동일한 사용자인지 확인하기 위한 세션 ID 등의 식별정보만 클라이언트에 쿠키로 저장하도록 제한해야 한다.


이메일 (SMTP, POP, IMAP)

이메일에서 사용되는 애플리케이션 계층 프로토콜에는 발신시 SMTP(Simple Mail Transfer Protocol), 수신시 POP(Post Office Protocol)가 있다.

SMTP

SMTP 프로토콜은 PC가 메일 서버로 메일을 보낼 때, 발신자의 메일 서버에서 수신자의 메일 서버로 메일을 중계할 때 모두 사용된다. HTTP 프로토콜과 달리 상태를 가지는 Stateful 프로토콜이라 전송 종료 명령이 보내져야 통신을 종료한다.

SMTP는 사용자 인증체계가 없기 때문에 악용의 소지가 있어 POP 서버의 인증 기능을 활용하거나 SMTP auth라는 프로토콜을 사용하는 등의 대안 방식이 있다.

POP

메일 서버에 저장된 메일을 확인할 때는 POP 프로토콜을 사용한다. 메일 수신 외에도 메일 건수, 용량 확인, 메일 삭제에도 POP 프로토콜을 사용한다

IMAP

POP 프로토콜은 클라이언트가 메일을 수신하면 메일 서버에 보관된 메일을 삭제하게 되어 있다. 이에 반해 IMAP 프로토콜은 클라이언트가 메일을 수신하더라도 메일 서버에서 수신한 메일을 지우지 않고 보관하게 되어있다.


PC 간 파일 공유

P2P(peer to peer)

파일 공유에 참여하는 각각의 컴퓨터가 서로 서버가 되기도 하고 클라이언트가 되기도 하는 방식. 파일 공유는 피어 투 피어 방식이기 때문에 중앙에서 관리하는 서버가 없다. 그래서 일단 컴퓨터가 네트워크에 연결되면 다른 모든 컴퓨터에게 자신이 연결되었다는 것을 통보하게 되고 통보를 받은 다른 컴퓨터는 자신의 정보를 응답으로 알려준다. 결과적으로 네트워크 전체에서 공유 가능한 컴퓨터들을 서로 식별할 수 있게 된다.

파일 공유 기능은 OS에 기본적으로 탑재되어 있고 OS마다 다른 파일 공유 프로토콜을 제공했으나 최근에는 다른 OS의 프로토콜도 지원할 수 있게 되었다.


파일을 전송하는 FTP

FTP(File Transfer Protocol)은 파일 전송 프로토콜이다. 주로 인터넷에 연결된 서버에 파일을 전송할 때 사용하는데 웹 서버로 웹 페이지를 전송할 때 자주 사용된다.

FTP에서는 크게 파일을 주고 받기 위한 데이터 커넥션과 명령어를 보내기 위한 컨트롤 커넥션, 두 가지 접속 형태를 사용한다.

방화벽이나 가정용 초고속 인터넷 라우터를 사용하는 경우 외부와의 통신을 차단하는 경우가 많은데 이 때는 패시브 모드를 사용해서 클라이언트에서 서버쪽으로 데이터 커넥션을 만들어 주어 파일을 전송한다.


원격으로 컴퓨터 제어하기(Telnet, SSH)

Telnet, SSH(Secure SHell)은 원격지의 컴퓨터를 명령어로 제어하기 위한 프로토콜이다. 최근에는 보안을 위해 통신 내용이 암호화되는 SSH를 많이 사용한다.

이 외에도 GUI 인터페이스를 사용한 도구나 제어 관련 프로토콜을 활용하는 방식들이 있다. 윈도우에 내장된 원격 데스크톱은 RDP(Remote Desktop Protocol) OS에 독립되어 범용으로 사용 가능한 VNC(Virtual Network Computing)은 RFS(Remote FrameBuffer)프로토콜을 사용한다.


Voice over IP(VoIP)와 영상 스트리밍

음성이나 동영상 데이터는 메일과 같은 텍스트 형태의 정보에 비해 상대적으로 데이터 용량이 크기 때문에 통신의 신뢰성보다는 전송 속도를 우선하는 UDP를 사용하고 전송 시에는 데이터를 압축하되 수신된 정보를 바로 재생할 수 있는 스트리밍 기술을 사용한다.

참고

책 <그림으로 배우는 Http & Network basic>

profile
삽질하며 깨닫고 배웁니다. (a.k.a 프로삽질러) + 이 구역의 회고왕

0개의 댓글