HTTP

지정한 IP 주소에 데이터 전달패킷이라는 통신 단위로 데이터 전달비연결성패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송(서버의 상태를 알 수 없음)비신뢰성패킷소실(중간에 패킷이 사라지기도 함)패킷 전달 순서 문제 발생(패킷이 순서대로 오지 않기도 함)프로그램

전송 계층IP 한계를 보완한 것연결지향 TCP 3 way handshake (가상연결)SYN : 접속요청ACK : 요청수락데이터 전달 보장순서 보장위 3가지를 통해서 신뢰할 수 있는 프로토콜이라고 함논리적인 연결을 보장(물리적 X)현재는 대부분 TCP 사용연결지향 TC

같은 IP내에서 프로세스 구분0 ~ 65535 할당가능0~1023 잘알려진 포트 사용하지 않는 것이 좋음FTP 20 21TELNET 23HTTP 80HTTPS 443

IP는 외우기 힘듦IP는 변경될 수 있음전화번호부로도 생각할 수 있음도메인 명을 IP 주소로 변환

Uniform: 리소스 식별하는 통일된 방식Resource: 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier: 다른 항목과 구분하는데 필요한 정보URI는 로케이터(locator) 이름(name) 또는 둘다 추가로 분류될 수 있음URL(리소스의 위치

URL 입력 -> HTTP 요청 메시지 생성 -> TCP/IP 연결 -> 패킷 생성 -> 요청 패킷 전달 -> 요청 패킷 도착 ->응답 패킷 전달 -> 응답 패킷 도착 -> HTML 랜더링

텍스트 기반의 통신 규약으로 인터넷에서 데이터를 주고받을 수 있는 프로토콜이다. 이렇게 규약을 정해두었기 때문에 모든 프로그램이 이 규약에 맞춰 개발해서 서로 정보를 교환할 수 있게 되었다.HTTP 특징클라이언트 서버 구조무상태 프로토콜(스테이스리스), 비연결성HTTP

리소스회원 관리가 있다면 회원이라는 개념이 리소스URI는 리소스만 식별리소스와 해당 리소스를 대상으로 하는 행위를 분리리소스 : 회원행위 : 조회, 등록, 삭제, 변경주요 메소드GET : 리소스 조회POST : 요청 데이터 처리, 주로 등록에 사용PUT : 리소스를 대

호출해도 리소스를 변경하지 않는다.Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면요?A: 안전은 해당 리소스만 고려한다. 그런 부분까지 고려하지 않는다.f(f(x)) = f(x)한 번 호출하든 두 번 호출하든 100번 호출하든 결과가 똑같다.멱등 메서드

데이터 전달 방식쿼리 파라미터를 통한 데이터 전송GET주로 정렬 필터(검색어)메시지 바디를 통한 데이터 전송POST, PUT, PATCH회원 가입, 상품 주문, 리소스 등록, 리소스 변경4가지 상황정적 데이터 조회이미지, 정적 텍스트 문서동적 데이터 조회주로 검색, 게

POST 기반 등록클라이언트는 등록될 리소스의 URI를 모른다.회원 등록 /members -> POSTPOST /members서버가 새로 등록된 리소스 URI를 생성해준다.HTTP/1.1 201 Created
 Location: /members/100컬렉션(Collec

클라이언트가 선호하는 표현 요청Accept: 클라이언트가 선호하는 미디어 타입 전달Accept-Charset: 클라이언트가 선호하는 문자 인코딩Accept-Encoding: 클라이언트가 선호하는 압축 인코딩Accept-Language: 클라이언트가 선호하는 자연 언어

컨텐츠의 길이를 알 수 있을 때한번에 보냄압축해서 보냄나눠서 보냄범위를 지정해서 데이터를 요청하고 보냄

유저 에이전트의 이메일 정보일반적으로 잘 사용되지 않음검색 엔진 같은 곳에서, 주로 사용요청에서 사용이전 웹 페이지 주소현재 요청된 페이지의 이전 웹 페이지 주소A -> B로 이동하는 경우 B를 요청할 때 Referer: A 를 포함해서 요청Referer를 사용해서 유

요청한 호스트 정보(도메인)요청에서 사용필수하나의 서버가 여러 도메인을 처리해야 할 때하나의 IP 주소에 여러 도메인이 적용되어 있을 때 페이지 리다이렉션웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 (리다이렉트)

클라이언트 인증 정보를 서버에 전달Authorization: Basic xxxxxxxxxxxxxxxx리소스 접근시 필요한 인증 방법 정의리소스 접근시 필요한 인증 방법 정의401 Unauthorized 응답과 함께 사용WWW-Authenticate: Newauth re

Set-Cookie: 서버에서 클라이언트로 쿠키 전달(응답)Cookie: 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달로그인로그인 후 모든 요청에 쿠키 정보 자동 포함예) set-cookie: sessionId=abcde1234; expire

데이터나 값을 미리 복사해 놓는 임시 장소캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.비싼 네트워크 사용량을 줄일 수 있다.브라우저 로딩 속도가 매우 빠르다.빠른 사용자 경험첫 번째두번째캐시 유효 시간이 초과하면, 서버를 통해 데이터를 다시 조회하고

캐시의 시간이 초과되면 서버에서 지속적으로 데이터를 계속 받아야 하므로 시간이 걸림 이것을 해결하기 위한 방법캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면304 Not Modified + 헤더 메타 정보만 응답(바디X)클라이언트는 서버가 보낸 응답 헤더 정

캐시 지시어(directives)Cache-Control: max-age캐시 유효 시간, 초 단위Cache-Control: no-cache데이터는 캐시해도 되지만, 항상 원(origin) 서버에 검증하고 사용Cache-Control: no-store데이터에 민감한 정보

중계자 역할? 원(origin)서버에 가기 전에 먼저 프록시 캐시를 들려서 필요한 캐시 확인이를 통해 원 서버로 가지 않아도 빠르게 접근이 가능함캐시 지시어(directives) - 기타Cache-Control: public응답이 public 캐시에 저장되어도 됨Cac