ch1

HTTP

• (15) http는 클라이언트에서 서버까지 일련의 흐름을 결정하고 있는 약속이다.
• HyperText Transfer Protocol
• 즉, 웹은 http라는 약속을 사용한 통신이다.
• (19) 등장 당시에는 ‘http-약속, html-문서, url-주소’로 한, 주로 텍스트 전송을 위한 프로토콜 이었지만, 여러가지 응용을 고려해서 기능이 계속 추가되었다.

TCP/IP

• (19) 인터넷을 포함하여, 일반적으로 사용되는 네트워크는 TCP/IP라는 프로토콜에서 움직이고 있다. http도 그 중 하나이다.
• (20) 서로 다른 하드웨어와 운영체제가 통신을 하기 위해선 규칙이 필요하다. 이를 프로토콜 이라고 한다. (Protocol: 약속)
• 이렇게 인터넷과 관련된 프로토콜들을 모은 것이 TCP/IP 이다.

계층(Layer)로 관리하는 TCP/IP

• (21) TCP/IP가 계층으로 관리하는 이유는 메리트가 있기 때문이다.
  → 하나의 프로토콜로 되어 있다면 어디선가 사양이 변경 되었을 때 전체를 바꿔야 하지만,
  계층화 되어있으면 사양이 변경된 해당 계층만 바꾸면 된다.
• 각 계층 내부는 자유롭게 설계 가능하다.

(1) http req ↔ (2) 조각내고 번호붙이고 ↔ (3) 주소 붙이고 ↔ (4) 하드웨어

클라이언트 (1-2-3-4) ↔ 서버 (4-3-2-1)

1. 애플리케이션 계층(유저)
   • http req를 보내는 것과 같이, HTTP가 여기에 포함된다.
   • 유저에게 제공되는 애플리케이션의 통신 결정
2. 트랜스포트 계층
   • 패킷(데이터 최소단위) 조각내서 번호 붙이기
   • TCP(Three-way Handshaking)
3. 네트워크 계층
   • 주소를 추가하는 등 이동경로 관리
   • IP
4. 링크 계층
   • 하드웨어적인 부분이 모두 여기서 이루어진다.

• (24) 각 계층을 거칠때마다 필요한 헤더(정보)를 추가한다.
• 반대로 수신측에서는 각 계층마다 사용한 헤더를 삭제한다.
• 이렇게 정보를 감싸는 것을 캡슐화라고 한다.

신뢰성을 담당하는 TCP

• 트랜스포트 계층에 속한다.
• Three-way Handshaking

배송을 담당하는 IP

• 네트워크 계층에 속한다.
• IP주소는 각 노드에 부여된 주소를 의미한다.
• MAC주소는 네트워크 카드에 할당된 고유 주소를 의미한다.
• 통신은 ARP를 이용해서 MAC 주소에서 한다.
  • ARP는 IP주소로 MAC주소를 찾는다.
  • 마치 택배 배송을 하듯: 모두가 최종 목적지를 알 필요 없이 다음 이동장소의 MAC주소만 알고 이동시킨다.

Three-way Handshaking (쓰리웨이 핸드셰이킹)

• 상대에게 확실하게 데이터를 보내기 위해 TCP는 쓰리웨이 핸드셰이킹을 사용한다.
• 패킷을 보내고 바로 끝내는 것이 아니라, 보내졌는지의 여부를 상대에게 확인한다.
  1. 송신측: SYN 플래그로 상대에게 패킷 보내고
  2. 수신측: SYN/ACK 플래그로 수신한 사실을 전달하고
  3. 송신측: ACK로 패킷 교환이 완료된 것을 전달한다.
• 1~3의 과정에서 통신이 끊기면 TCP는 패킷을 재전송한다.

*플래그: 특정 동작을 수행할지 말지 결정하는 (보통 1비트인) 변수

*SYN synchronize, ACK acknowledge,

정리하자면,

(1) 애플리케이션 계층에서 http req가 들어오면

(2) 트랜스포트 계층에서 TCP로 데이터 분해 및 정확히 도착했는지 확인하고(Three-way Handshaking)

(3) 네트워크 계층에서 IP로 패킷을 상대에게 전달한다.

DNS

(28) 도메인명 ↔ IP 주소 변환해주는 서비스 제공

URL, URI

(32)

URL은 네트워크상의 리소스 위치(Locator),
URI는 리소스 식별자: 식별하기 위한 문자열 전반을 나타낸다 (Identifier)

---

ch2

(38) 단 한번의 통신만을 가정 했을 때, http는 클라이언트와 서버의 역할을 명확하게 구분하고 있다.

• req: 메소드, URI, 프로토콜 버전, 리퀘스트 헤더필드, 엔티티 (104)
• res: 프로토콜 버전, 상태코드+상태메시지, 리스폰스 헤더필드, 바디 (105)
• req, res 관련한 자세한 내용은 ch3

Stateless

• http 프로토콜은 전에 보냈던 리퀘스트나 리스폰스를 스스로 기억할 수 있는 구조가 아니다.
  이는 많은 데이터를 빠르고 확실하게 처리하는 범위성(Scalability)을 확보하기 위해서다.
• 하지만, ‘로그인 후 누가 어떤 리퀘스트를 보냈는지 파악’하기 위한 상황과 같이, 상태 유지의 필요성이 점차 대두되었고, 이에 쿠키가 도입되었다.

쿠키

• 서버 CPU와 메모리 리소스 절약을 돕는 Stateless의 이점은 살리며 문제를 해결하기 위해 쿠키 개념이 도입되었다.
• 클라이언트에서 리퀘스트를 보내면
  → 서버에서 쿠키를 발행한다.
  → 리스폰스 Set-Cookie 헤더필드에 의해 쿠키를 클라이언트에 보존한다.
  → 그 다음 리퀘스트부터는 자동으로 쿠키값이 넣어져 송신되고, 서버에선 이를 확인하는 구조다.

method(메소드)

(52) 리퀘스트URI로 지정한 리소스에 요청을 보내는 경우, 메소드라 불리는 명령이 있다.

• 메소드는 리소스에 어떠한 행도을 하기 원하는지 지시하기 위해 존재한다.

TCP 지속 연결 (Persistent Connections)

• (54) 초반엔 주고받을 파일이 txt 정도뿐이었으니, TCP 커넥션 연결 <> http req/res <> TCP 커넥션 종료로도 문제가 없었다.
• 하지만 http가 널리 보급되며 (ex) 하나의 html에 여러 이미지 담겨 있다거나와 같은 상황이 생김
  → TCP 커넥션 연결 <> http req/res <> TCP 커넥션 종료 를 재차 반복하기 힘들어짐
• 이에 지속 연결이 등장한다:
  어느 한쪽이 명시적으로 연결을 종료하지 않는 이상 TCP 연결을 계속 유지한다.
• TCP 커넥션 연결 <> http req/res http req/res http req/res <> TCP 커넥션 종료
• 지속 연결은 http 1.1에서는 표준 동작이지만, 1.0에서는 정식 사양이 아니었다.
• 이로 인해 (1) 서버 부하는 줄어들고, (2) 웹페이지 역시 빠르게 표시 가능해졌다.

파이프라인화(HTTP pipelining)

• (57) 지속 연결은 여러 리퀘스트를 보낼 수 있는 파이프라인화를 가능하게 한다.
• TCP 커넥션 연결 <> 1.http req 2.http req 3.http req 1.http res 2.http res 3.http res <> TCP 커넥션 종료
• 이와 같이 여러 리퀘스트를 병행해서 보내는 것이 가능해졌고, 일일이 리스폰스를 기다릴 필요가 없어졌다.

---

ch3

HTTP 메시지

*(65) 인코딩(변환), 페이로드(부가물)

• 데이터를 전송할때 인코딩을 하면 다량의 엑세스를 효율 좋게 처리할 순 있으나,
  인코딩을 해야하기에 CPU등의 리소스는 더욱 소비하게 된다.
• 메시지는 http 통신의 기본 단위(메시지 헤더, 메시지 바디)
  엔티티: 리퀘스트와 리스폰스의 페이로드(payload, 부가물)로 전송되는 정보(엔티티 헤더, 엔티티 바디)
• http 메시지 바디의 역할은 엔티티 바디를 운반하는 일이다.
  이때문에 기본적으로 메시지 바디는 엔티티 바디와 동일하지만,
  전송 코딩(아래 설명)이 적용된 경우에는 엔티티 바디의 내용이 변하기때문에 메시지 바디와 달라진다.
  - (66) 압축해서 보내는 콘텐츠 코딩(Content Codings)
  - (67) 분해해서 보내는 청크 전송 코딩 (Chunked transfer Coding)

멀티파트(multipart)

(68) 여러개의 데이터를 보내는 멀티파트

• 이미지, 텍스트, 영상 등 여러 종류의 데이터를 수용하는 방법이다.
  주로 이미지나 텍스트 파일 등을 업로드할 때 사용한다.
• http도 멀티파트에 대응하고 있기에 하나의 메시지 바디 내부에 엔티티를 여러개 포함시켜 보낼 수 있다.
• 그 종류 중 하나로 multipart/form-data: 웹 폼으로부터의 파일 업로드에 사용 된다.
• http 메시지로 멀티파트를 사용할 때는 Content-type 헤더 필드를 사용한다.

레인지 리퀘스트 (Range request)

• 레인지 리퀘스트: 범위를 지정해서 리퀘스트하는 것
• (71) 리줌이라는 기능을 통해 이전에 다운로드한 곳에서부터 다운로드를 재개할 수 있다.

콘텐츠 네고시에이션(Content Negotiation)

(73) 최적의 콘텐츠를 돌려주는 콘텐츠 네고시에이션

• 같은 콘텐츠임에도 여러개의 페이지를 지닌 경우가 있다.
  예를 들어, 서로 다른 언어를 사용하는 브라우저가 같은 URI에 접근할 시, 각각 영어판, 한국어판과 같이 제공을 해야한다.
• 이러한 경우처럼 클라이언트와 서버가 리소스에 대해 교섭하는 것을 콘텐츠 네고시에이션이라고 한다.
• 판단 기준은 req 메시지에 포함된 헤더 필드가된다.

서버 구동형 네고시에이션

• 서버 측에서 네고시에이션하는 방식
• 서버 측에서 리퀘스트 헤더 필드의 정보를 참고해서 자동적으로 처리한다.
• 브라우저가 보내는 정보를 근거로 하기 때문에 유저에게 정말로 적절한 것이 선택되었다고 보기 어렵다.

에이전트 구동형 네고시에이션

• 클라이언트 측에서 네고시에이션하는 방식
• 브라우저에 표시된 선택지 중에서 유저가 수동으로 선택한다.
  예를 들어, OS의 종류나 브라우저의 종류 등에 의해서 PC용과 스마크폰용 웹 페이지를 자동으로 전환하는 것

트랜스퍼런트 네고시에이션

• 서버 구동형과 에이전트 구동형을 혼합한 것
• 서버와 클라이언트가 각각 콘텐츠 네고시에이션을 하는 방식

---

ch4 상태코드

ch5

가상 호스트(Virtual host)

• 한 개의 물리적인 서버로 여러대가 있는 것처럼 설정이 가능하다.
  e.g. 웹 호스팅 사업자는 한대의 서버에 여러 고객의 웹 사이트를 넣을 수 있다.
• 클라이언트는 → [도메인명 → DNS → IP주소] → 서버에 액세스 하는데,
  결국 리퀘스트 서버에 도착한 시점에는 IP주소를 기준으로 접근을 하다보니
  www.a.kr , www.b.kr과 같이, 각각의 도메인에서 온 요청이 구분이 되지 않는다.
• 같은 IP주소에서 다른 호스명과 도메인명을 지닌 여러개의 웹사이트가 실행되고 있기 때문에
  이를 해결하기 위해서는 http 리퀘스트를 보낼 때

1. 호스트명과 도메인명을 완전하게 포함한 URI를 지정하거나
2. 반드시 HOST 헤더필드에 어떤 도메인인지를 지정해야한다.

http는 클라이언트와 서버 이외에도 프록시, 게이트웨이, 터널과 같은 통신 중계 프로그램이 존재한다.

• 이러한 것들은 (1) 다른 서버에 리퀘스트를 중계하고 (2) 받은 리스폰스를 클라이언트에 반환하는 역할을 한다.

프록시(Proxy)

(96) 서버와 클라이언트 양쪽 역할을 하는 중계 프로그램

• 프록시 사용이유
  1. 캐시를 사용하여 네트워크를 효율적으로 사용할 수 있다.
  2. 특정 액세스를 제한할 수도 있으며
  3. 액세스 로그 획득 등, 다양한 목적으로 사용된다.
• 프록시 서버를 경유해서 리퀘스트와 리스폰스를 릴레이할 때마다 “Via” 헤더 필드에 정보를 추가한다.
• 프록시 사용방법은
  1. 캐싱을 하는지 안하는지의 여부와
  2. 메시지를 변경하는지 안하는지의 여부로 분류된다.

캐싱 프록시

• 프록시로 리스폰스를 중개할때, 프록시 서버상에 리소스의 개시를 보존해두는 프록시
• 다시금 같은 리소스에 대한 리퀘스트가 올 때 굳이 오리진 서버에서 가져오지 않고 캐시를 리스폰스로 되돌려준다.
• 오리진 서버(Origin Server): 리소스 본체를 가진 서버

투명 프록시

• 중계할때 메시지를 변경하지 않는 타입의 프록시 이다.
• 이는 메시지를 변경하는 비투과 프로시

게이트웨이(Gateway)

• 프록시와 유사하지만, 게이트웨이의 경우 그 다음의 서버가 http 프로토콜 이외의 통신을 하는 경우 사용한다.
• 암호화 등으로 안전하게 접속하여 통신 안정성을 높인다.
• e.g. 쇼핑 사이트에서 신용카드 견제 시스템이 연계되어 있는 경우

터널(Tunnel)

• 요구에 따라 다른 통신과의 경로를 확립한다.
• (클라이언트가 SSL과 같은 암호화 통신을 통해) 서버와 안전하게 통신하기 위해 사용한다.

캐시

• 캐시는 리소스의 사본을 가리킨다.
• (1) 프록시 서버에 보관하거나 (2) 클라이언트 로컬 디스크에 보관할수도 있다.
• 캐싱 서버 === 캐싱 프록시, 프록시 서버상에 리소스의 사본을 보존한다.
  • 같은 데이터를 얻기 위해 굳이 오리진 서버까지 가지 않아도 되기 때문에
  1. 클라이언트는 가깝게 리소스를 얻을 수 있고
  2. 서버는 같은 리퀘스트를 매번 처리하지 않아도 된다.
• 캐싱 서버에 캐시가 있더라도 항상 캐시를 돌려주는 것은 아니다. 왜냐하면 유효성 문제가 있기 때문이다.
  • 오리진 서버에 있는 원본 리소스가 갱신되었을 경우 ‘이 캐시는 오래되었다고 판단’하여 다시금 오리진 서버로 다녀올 수도 있는 것이다.
• 클라이언트 측에도 캐시가 있다.
  • 브라우저도 캐시를 가질 수 있는데, 유효한 캐시의 경우 로컬 디스크로부터 불러오게 된다.
  • 물론 이 역시 유효성 확인을 위해 다시금 오리진 서버에 가기도 한다.

---

ch6

HTTP 메시지

• (104) 메시지 헤더는 클라이언트와 서버 처리에 필요한 주요 정보를 담고 있다.
• 메시지 바디에는 사용자와 리소스를 필요로 하는 정보가 있다.

리퀘스트의 HTTP 메시지

• 메소드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성되어 있다.

리스폰스의 HTTP 메시지

• HTTP 메시지와 HTTP 버전, 상태 코드(코드와 설명), HTTP 헤더 필드 등으로 구성되어 있다.

HTTP 헤더필드

• (106) http 메시지 구성요소 중 하나로, http 메시지에 관한 다양한 정보를 가지고 있다.

end-to-end 헤더

이 카테고리에 분류된 헤더는 리퀘스트나 리스폰스의 최종 수신자에게 전송된다.

hop-by-hop 헤더

• 이 카테고리에 분류된 헤더는 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있다.
• HTTP/1.1과 그 이후에서 사용되는 hop-by-hop 헤더는 Connection 헤더 필드에 열거해야 한다.
• hop-by-hop 8개 (이외에는 모두 End-by-end 헤더에 분류)

- `Connection`
- `Keep-Alive`
- `proxy-Authenticate`
- `Proxy-Authorization`
- `Trailer`
- `TE`
- `Transfer-Encoding`
- `Upgrade`

Connection 헤더필드

(123)

1. 프록시에서 더 이상 전송하지 않을 헤더 필드(hop-by-hop)를 지정할 수 있다.
2. http/1.1에서는 지속적 접속이 디폴트로 되어있다. 이로인해 추가 리퀘스트 보낼 수 있다.
   서버측에서 명시적으로 접속을 끊고 싶을 때에는 Connection: Close를 지정하면 된다.
   http/1.1 이전 버전에서 지속적 접속을 위해선 Connection: Keep-Alive 를 지정해줘야한다.
   - Keep-Alive 는 1.1까지만 쓴다. 2.0부터는 사용불가하다.

쿠키를 위한 헤더필드

(172) 유저 식별과 상태 관리에 사용

• 리퀘스트(클라이언트) Cookie 헤더
• 리스폰스(서버) Set-Cookie 헤더