지정한 IP 주소(IP Address)에 데이터 전달패킷(Packet)이라는 통신 단위로 데이터 전달비연결성 \- 패킷을 받을 대상이 없거나 서비스 불능 상태여도 패킷 전송비신뢰성 \-중간에 패킷이 사라지면? \-패킷이 순서대로 안오면?프로그램 구분 \- 같은
"URI는 로케이터(locaator), 이름(name) 또는 둘다 추가로 분류될 수 있다.Uniform : 리소스 식별하는 통일된 방식Resource : 자원, URI로 식별할 수 있는 모든 것(제한 없음)Identifier : 다른 항목과 구분하는데 필요한 정보URL
HyperText Transfer ProtocolHTML, TEXTIMAGE, 음성, 영상, 파일JSON, XML(API)거의 모든 형태의 데이터 전송 가능서버간에 데이터를 주고 받을 때도 대부분 HTTP 사용지금은 HTTP 시대!TCP : HTTP/1.1 , HTTP
스테이트리스(Stateless)서버가 클라이언트의 상태를 보존 X장점 : 서버 확장성 높음(스케일 아웃)단점 : 클라이언트가 추가 데이터 전송상태유지 - Stateful상태 유지 : 중간에 다른 점원으로 바뀌면 안된다.(중간에 다른 점원으로 바뀔 때 상태 정보를 다른
요청 메시지start-line = request-line/status-linerequest-line = method SP(공백) request-target SP HTTP-version CRLF(엔터)HTTP 메서드 (GET: 조회)요청대상(/search?q=hello&
URI(Uniform Resource Identifier)리스소의 의미는 뭘까? \-회원을 등록하고 수정하고 조회하는게 리소스가 아니다! \-예) 미네랄을 캐라 -> 미네랄이 리소스 \-회원이라는 개념 자체가 바로 리소스다.리소스를 어떻게 식별하는게 좋을까? \
주요 메서드GET: 리소스 조회POST : 요청 데이터 처리, 주로 등록에 사용PUT : 리소스를 대체, 해당 리소스가 없으면 생성PATCH : 리소스 부분 변경DELETE : 리소스 삭제리소스 조회서버에 전달하고 싶은 데이터는 query(쿼리 파라미터,쿼리 스트링)를
안전(Safe Methods)멱등(Idempotent Methods)캐시가능(Cacheable Methods)호출해도 리소스를 변경하지 않는다Q: 그래도 계속 호출해서, 로그 같은게 쌓여서 장애가 발생하면?A: 안전은 해당 리소스만 고려한다. 그러한 부분까지 고려하지
데이터 전달 방식은 크게 2가지쿼리 파라미터를 통한 데이터 전송 \-GET \-주로 정렬 필터(검색어)메세지 바디를 통한 데이터 전송 \-POST,PUT,PATCH \-회원 가입, 상품 주문, 리소스 등록, 리소스 변경이미지, 정적 텍스트 문서조회는 GET 사용
HTTP API - 컬렉션 \-POST 기반 등록 \-예) 회원 관리 API 제공HTTP API - 스토어 \-PUT 기반 등록 \-예) 정적 컨텐츠 관리, 원격 파일 관리HTML FORM 사용 \-웹 페이지 회원 관리 \-GET, POST만 지원회원 목록
1xx(Informational) : 요청이 수신되어 처리중2xx(Successful): 요청 정상 처리3xx(Redirection): 요청을 완료하려면 추가 행동이 필요4xx(Client Error): 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행 할 수
헤더 분류 \-General 헤더 : 메시지 전체에 적용되는 정보, 예) Conntecion:close \- Request 헤더 : 요청 정보, 예) User-Agent: Mozila/5.0(Macintosh;..) \- Response 헤더 : 응답 정보,
표현
클라이언트가 선호하는 표현 요청Accept: 클라이언트가 선호하는 미디어 타입 전달Accept-Charset: 클라이언트가 선호하는 문자 인코딩Accept-Encoding: 클라이언트가 선호하는 압축 인코딩Accept-Language: 클라이언트가 선호하는 자연 언어협
전송 방식 설명 단순 전송 압축 전송 분할 전송 범위 전송
From : 유저 에이전트의 이메일 정보Referer : 이전 웹 페이지 주소User-Agent : 유저 에이전트 애플리케이션 정보Server : 요청을 처리하는 오리진 서버의 소프트웨어 정보Date : 메시지가 생성된 날짜HOST : 요청한 호스트 정보(도메인)Loc
내가만든쿠키...Set-Cookie : 서버에서 클라이언트로 쿠키 전달(응답)Cookie : 클라이언트가 서버에서 받은 쿠키를 저장하고, HTTP 요청시 서버로 전달모든 요청에 사용자 정보가 포함되도록 개발 해야함브라우저를 완전히 종료하고 다시 열면?예) set-coo
데이터가 변경되지 않아도 계속 네트워크를 통해서 데이터를 다운로드 받아야 한다.인터넷 네트워크는 매우 느리고 비싸다.브라우저 로딩 속도가 느리다.느린 사용자 경험캐시 덕분에 캐시 가능 시간동안 네트워크를 사용하지 않아도 된다.비싼 네트워크 사용량을 줄일 수 있다.브라우
캐시 유효 시간이 초과해도, 서버의 데이터가 갱신되지 않으면304 Not Modified + 헤더 메타 정보만 응답(바디 X)클라이언트는 서버가 보낸 응답 헤더 정보로 캐시의 메타 정보를 갱신클라이언트는 캐시에 저장되어 있는 데이터 재활용결과적으로 네트워크 다운로드가
Cache-Control: 캐시 제어Pragma : 캐시 제어(하위 호환)Expires : 캐시 유효 기간(하위 호환)캐시 지시어(directives)Cache-Control: max-age \-캐시 유효 시간, 초 단위Cache-Control: no-cache \
확실한 캐시 무효화 응답Cache-Control: no-cache, no-store, must-revalidatePragma:no-cache(HTTP 1.0 하위 호환)Cache-Control: no-cache \-데이터는 캐시해도 되지만, 항상 원 서버에 검증하고
수많은 트래픽이 한번에 몰렸을 때, 아무리 성능이 뛰어난 서버라고 해도 단 한대의 서버로는 모든 트래픽을 감당하기 힘들어졌다. 이 때 쏟아지는 트래픽을 여러 대의 서버로 분산시켜주는 기술이 로드 밸런싱이다!!!로드 밸런싱이란 말 그대로 서버가 처리해야 할 업무 혹은 요
프록시의 사전적 의미는 '대신', '대리'이다. 말 그대로 PC들간 통신을 할 때 직접하지 않고 중간에서 대리로 통신을 하는 것을 '프록시' 라고 하고 중계 역할을 하는 것을 '프록시 서버' 라고 부른다. 즉, 클라이언트와 서버 사이의 '중계 서버'라고 생각하면 된다.