배고픈 개발자 이야기

그림으로 배우는 네트워크 1~4장 본문

전산학/네트워크

그림으로 배우는 네트워크 1~4장

이융희 2019. 9. 8. 11:29
728x90

제1장 웹과 네트워크의 기본에 대해 알아보자

브라우저에 Client가 url을 입력하면 웹Server로 부터 리소스를 얻음

HTTP프로토콜 - Client로부터 Server까지의 흐름을 결정하는 것

네트워크의 기본은 TCP/IP - HTTP를 이해하는데 필요한 개념만

-인터넷과 관련된 모든 프로토콜을 의미함

계층화된 것은 사양변경시 한계층만 바꾸면 됨/설계 간편 메리트가 있기 때문

 

1.Application Layer 역할

유저에게 제공되는 애플리케이션에서 사용되는 통신의 움직임을 결정(FTP, DNS)

2.Transport Layer

TCP/UDP프로토콜, 1.에 네트워크로 연결되어 있는 2대의 컴퓨터의 데이터흐름을 제공

3.Network(Internet) Layer

네트워크 상의 패킷의 이동을 다룸, 어떠한 경로(네트워크, 절차)를 따라 상대에게 패킷을 보낼지 하나의 길을 결정함.

4.Link(Data Link, Network Interface) Layer

운영체제가 제어하는 네트워크에 접속하는 하드웨어를 다룸

-디바이스 드라이버, 네트워크 인터페이스 카드(NIC), 물리적부분(케이블)을 포함함

 

송신(Client) - HTTP -> TCP -> IP -> NETWORK : 계층마다 헤더 추가

  • HTTP 리퀘스트 -> 데이터 조각내어 +(안내번호, 포트번호) -> 수신지 MAC 주소 추가 -> 네트워크로 송신

수신(Server) - NETWORK -> IP -> TCP -> HTTP서버 : 계층마다 헤더 삭제

  • 수신측 HTTP에 도달하면 HTTP리퀘스트 내용 수신

Ethernet 헤더(네트워크 프레임) + IP 헤더(IP 데이터그램) + TCP 헤더(TCP 세그먼트) + HTTP 데이터(HTTP 메시지)

IP 프로토콜 - 개개의 패킷을 전달하는 역할

IP주소 : 각노드에 부여된 주소 / MAC주소 - 각네트워크 카드에 부여된 주소

ARP프로토콜로 수신지의 IP주소를 바탕으로 MAC주소를 조사하여 네트워크를 찾아감

목적지까지 중계(라우팅) - 다음 네트워크 까지만의 대략적인 주소만 알고 중계

신뢰성을 담당하는 TCP - 신뢰성 있는 바이트 스트림 서비스 제공

  • TCP 세그먼트라고 불리는 단위패킷으로 분해하여 관리

3-Way Handshaking - 상대방에게 보내졌는지 확인, TCP플래그 (SYN/ACK사용)

(송신) SYN로 접속과 동시에 패킷 전송 -> (수신) SYN/ACK로 송신측과 접속, 패킷수신 -> (송신) ACK플래그를 보내 패킷교환이 완료됨을 알림

-이 과정에서 문제 발생시 TCP는 패킷을 재전송함

-책설명이 틀린것 같음 3-Way Handshaking은 초기 연결을 하기 위한것이며 SYN/ACK신호를 이용하여 재전송하는것은 맞음

DNS는 Application Layer - 도메인 이름 <-> IP주소 이름 확인을 제공

HTTP 통신

(Client) 주소입력 - (DNS) IP제공 - (Client) HTTP request - (TCP)TCP 세그먼트(번호부여)전송 - (IP)중계 배송 - (TCP) 패킷수신 - (HTTP) request 처리, response도 동일하게 client에 반환 - (server) 리소스처리

제2장 간단한 프로토콜 HTTP - HTTP/1.1

2.1 HTTP는 클라이언트와 서버간에 통신을 한다

TCP/IP와 마찬가지로 반드시 한 번의 통신에 클라이언트와 서버역할로 통신을 한다.

2.2 리퀘스트와 리스폰스를 교환하여 성립

Request

Get /index.html HTTP /1.1 Host: www.youngjin.com
Get은 메소드 / index.html은 요구대상 리소스(Request URI)

Host는 리퀘스트 헤더필드와 엔티티로 구성

Response

  • HTTP/1.1 200 OK

    Date: Tue, 10 Jul 2012 06:50:15 GMT

    Content-Length: 362

    Content-Type: text/html

    <html>~

Date부터 헤더필드 / 빈줄 다음부터 body로 리소스 본체

2.3 HTTP는 상태를 유지하지 않는 프로토콜

HTTP는 stateless프로토콜 / Request와 Response를 교환하는 동안 상태관리를 하지 않음 - 이미 전송된 요청은 남아있는 기록이 없음

-이는 많은 데이터를 매우 빠르고 확실하게 처리하는 범위성(scalability)를 확보

-쇼핑사이트와 같이 다른페이지에 이동하더라도 로그인 상태를 유지하기 위해 쿠키라는 기술이 도입(계속 상태관리 가능해짐)

2.4 리퀘스트 URI로 리소스를 식별

URI필드 중 Host를 따로 분리하여 전송할 수도 있음

2.5 서버에 임무를 부여하는 HTTP 메소드

GET - 리소스 획득 : 가져올 리소스는 서버가 해석한 결과

리퀘스트 : If-Modified-Since: 날짜면 해당날짜에 갱신된 경우에만 리소스전송, 갱신이 되지 않았으면 304 Not modified 리스폰스만 돌려준다.

POST - 엔티티 전송 : GET으로도 엔티티를 전송할 수 있지만 일반적으로 사용

리퀘스트 : Content-Length , /submit.cgi가 수신한 데이터의 처리결과를 돌려줌

PUT - 파일 전송 : FTP에 의한 파일 업로드와 같이 리퀘스트중 포함된 엔티티를 보존하도록 요구합니다.

리퀘스트 : Content-Length, Content-Type, 상태코드 204 No Content 되돌려줌 요청한 파일 작성되어 있음

HEAD - 메시지 헤더 취득 : GET과 같은 기능을 하지만 body는 돌려주지 않음

URI 유효성과 리소스 갱신 시간을 확인하는 목적으로 사용됨

DELETE - 파일삭제 : PUT과 반대로 동작, 지정된 리소스의 삭제를 요구

204 No Content 리스폰스 돌려줌, 서버상의 리소스는 삭제되어 있음

OPTIONS - 제공하고 있는 메소드의 문의 : 리소스가 제공하고 있는 메소드 조사용

TRACE - 경로조사 : Max-Forwards 내용 돌려줌

CONNECT - 프록시에 터널링 요구 : TCP통신을 터널링 시키기 위해 사용됨

주로 SSL, TSL등의 프로토콜로 암호화된것을 터널링 시키기 위해서 사용됨

200 OK 리스폰스 후 터널링 시작

2.7 지속 연결로 접속량을 절약

HTTP초기에는 통신 할 때마다 연결 및 종료할 필요가 있었습니다.

초기에는 데이터양이 적었기 때문에 문제가 없었지만 커지면서 문제가 생김

따라서 한쪽의 명시적 종료가 없는 이상 지속 연결로 많은 리퀘스트를 없애 불필요한 통신량 줄임

**파이프라인화**

지속적인 연결이 가능해지면서 여러개의 Request를 Response를 하나하나 기다리지 않고 같이 받을 수 있음(빨라짐)

2.8 쿠키를 사용한 상태 관리

쿠키는 Request와 Response에 정보를 추가하여 상태를 관리하는 시스템

-서버에서 보내진 set-cookie라는 헤더 필드에 의해 쿠키를 클라이언트에 보존함

다음번에 클라이언트가 Request를 보낼 때 쿠키 정보를 담아서 전송함 - 서버는 클라이언트를 식별할 수 있고, 서버에서 이전기록을 찾을 수 있음

제3장 HTTP 정보는 HTTP 메시지에 있다

HTTP로 데이터를 전송할 경우 인코딩을 통하여 전송 효율을 높일 수 있음

다량의 엑세스 효율 높일 수 있음, 컴퓨터에서 인코딩 처리를 하기 때문에 CPU 리소스는 보다 많이 소비하게됨

엔티티를 압축(Content Codings)해서 보내기도 함, 수신측에서 디코딩하여야함

엔티티 바디를 분할하여 전송 - 청크 전송 코딩(다 전송전에 표시가능)

메일의 경우 파일첨부가능 - MIME(인터넷 메일 확장 사양) 멀티파트라고 하는 여러 종류의 데이터를 수용하는 방법을 사용하고 있음(주로 이미지나 텍스트파일 업로드에 사용), boundary와 range를 통해 나누어진 범위를 표시함

레인지 리퀘스트와 리줌을 통해 이전에 다운받았던 부분부터 다시 다운받을수 있음 레인지 리퀘스트에 의한 리스폰스에서는 206 Partial Content라는 상태가 돌아옴 또한 복수범위의 레인지 리퀘스트에서는 multilpart/byteranges로 리스폰스가 되돌아옴, 서버가 레인지 리퀘스트를 지원하지 않는 경우 200 OK가 리스폰스로 되돌아옴

영어판/한국어판 같은 URI로 페이지를 (영어/한국어 브라우저) 마다 표시하는 구조를 콘텐츠 네고시에이션이라고 부름, 클라이언트가 서버가 제공하는 리소스에 교섭을 하는것, 클라이언트에 더욱 적합한 리소스를 제공하기 위한 구조

-언어와 문자 세트, 인코딩 방식을 기준으로 판단

  • 서버 구동형 / 에이전트 구동형 / 트랜스페어런트 네고시에이션

  • 자바스크립트를 통해 OS, 브라우저 종류에 따라 자동으로 웹페이지를 PC용과 스마트폰용으로 전환하는것이 가능함

제4장 결과를 전달하는 HTTP 상태 코드

클라이언트가 서버에 리퀘스트를 보냈을 때 그 결과가 어찌되었는지 알려주는것이 상태코드의 역할

숫자의 첫자리는 리스폰스 클래스

  • 1xx / informational / 리퀘스트를 받아들여 처리중

  • 2xx / Success / 리퀘스트를 정상적으로 처리했음

  • 3xx / Redirection / 리퀘스트를 완료하기 위해서 추가 동작이 필요

  • 4xx / Client Error / 서버는 리퀘스트 이해 불가능

  • 5xx / Server Error / 서버는 리퀘스트 처리 실패

200 OK

204 No Content - 성공했지만 돌려받는 리소스가 없음

206 Partial Content - Range에 의한 부분적 Get리퀘스트를 받았음을 표시 리스폰스에는 Content Range로 지정된 번위의 엔티티가 포함되게 됨

301 Moved Permanently - 새로운 URI로 바꿔야할 필요성이 있을 때

302 Found - 새로운 URI이용해야함 하지만 일시적일 때

303 See Other - 302와 같지만 GET메소드로 URI를 얻어야함을 명시함

304 Not Modified - 조건부 리퀘스트를 했을때, 리소스는 있지만 조건에 맞지않아 돌려주지 않을 때

307 Temporary Redirect - 302와 같은 의미지만 브라우저마다 동작이 다를 수 있음 POST - GET치환 금지되어 있지만 다르게 동작할 수도 있음

400 Bad Request - 200 OK와 같이 취급(브라우저), 리퀘스트 구문이 잘못되었음

401 Unauthorized - 인증이 필요함, 1번 리퀘스트한 경우 인증이 실패함을 나타냄

403 Forbidden - 리소스에 엑세스가 거부됨을 나타냄, 권한 문제

404 Not Found - 리소스가 서버에 없음

500 Internet Server Error - 서버에서 리퀘스트 처리하는 중 에러 발생, 일시적이거나 웹애플리케이션 문제 발생

503 Service Unavailable - 서버가 과부하거나 일시적으로 리퀘스트 처리 불가

'전산학 > 네트워크' 카테고리의 다른 글

후니의 CISCO 네트워크 8-11장  (0) 2019.09.08
후니의 CISCO 네트워크 4-7장  (0) 2019.09.08
후니의 CISCO 네트워크 1-3장  (0) 2019.09.08
그림으로 배우는 네트워크 5~6장 (feat.Quiz)  (0) 2019.09.08
'전산학/네트워크' Related Articles more
Comments