녕의 학습 기록

♪ 학습 내용 캐시 / 검증헤더와 조건부요청 * 캐시 동작 웹 브라우저에 캐시가 없다면 같은 요청을 보내도 매번 계속 서버로부터 데이터를 다운로드 받아야 한다. 느린 사용자 경험. 웹 브라우저에 캐시를 적용하면 다르다. 이 경우 첫 번째 요청에서는 당연히 서버로부터 데이터를 받아와야한다. 하지만 캐시를 적용하지 않았을 때와는 달리, 서버의 HTTP 응답 메시지에 cache관련 헤더가 있고, 이 응답 결과를 웹 브라우저의 캐시 저장소에 저장하게 된다.(쿠키와 같은 원리) 그리고 두번째 요청을 보낼 때면 먼저 이 브라우저 캐시를 뒤지고, 같은 데이터가 있으면 캐시에서 조회한다. 이렇게 되면 네트워크를 사용하지 않아도 되고, 속도가 매우 빠르다. 빠른 사용자 경험. 평소에 웹 브라우저 중 한 번 들어갔던 곳은..

♪ 학습 내용 전송 방식에 따른 헤더, 일반/특수 정보를 담은 헤더, 쿠키 * 전송방식에 따른 HTTP 헤더 HTTP 메시지 바디 내 데이터의 전송 방식은 여러 가지가 있다. 그리고 이 전송 방식 정보를 담는 헤더들도 여러가지이다. - 단순 전송 단순 전송 시에 메시지 바디 내 데이터의 길이를 Content-length 헤더로 넘겨준다. - 압축 전송 압축 전송 시에 압축 형식에 대한 정보를 Content-Encoding 헤더로 넘겨준다. - 분할 전송 " Transfer-Enconding: chunked " chunked -> 덩어리로 쪼개 분할 전송시에는 content-length 헤더가 없다. 왜? 예상이 가지도 않고, chunck 마다 안에 길이 정보가 포함되어있기 때문. - 범위 전송 서버에 데..

♪ 학습 내용 HTTP 헤더 / 표현 헤더 / 협상 헤더 / 협상과 우선 순위 * HTTP 헤더(Header) HTTP 헤더는 HTTP 전송에 필요한 모든 부가 정보를 담고 있다. 과거에는 Entity 헤더 포함 4가지의 헤더로 분류 되었다. Entity 헤더는 HTTP 메시지 바디에 대한 정보를 가지고 있는 헤더이다. 요청이나 응답에서 메시지 본문 안에 'entity 본문'을 담아 전송하면 그 엔티티 본문의 데이터를 해석할 수 있도록 정보를 제공하는 것이 바로 Entity 헤더. 근데 헤더에 대한 이러한 분류에 변화가 생겼고 엔티티(Entity) -> 표현(Representation)으로 용어도 변하였다. 메시지 본문은 실제 데이터인 표현 데이터를 포함하고 이에 관한 정보를 표현 헤더가 제공!! 리소스..

♪ 학습 내용 각 번호대의 HTTP 상태코드 / PRG * 상태코드란? 상태코드는 클라이언트가 서버로 보낸 요청이 어떻게 처리가 되었는지를 서버가 응답해주는 기능. 상태코드는 숫자로 이루어져 있고, 각 번호 대마다 의미하는 바가 다르다. * 1XX 대 상태코드 1XX대 상태 코드는 클라이언트의 요청이 수신되었고 현재 처리중이라는 의미이다. 실제로는 거의 사용하지 않는 상태코드라고 한다. * 2XX 대 상태코드 200번대 상태 코드는 요청이 성공적으로 처리되었음을 의미한다. - 200 OK 단순하게 요청이 성공되었음을 뜻한다. -201 Created 클라이언트의 요청이 POST 같은 메서드인 경우, 요청이 성공하면 서버에서 새로운 리소스가 생성된다. 이때 새로운 리소스 생성의 성공을 의미하고, 응답메시지에..

♪ 학습 내용 서버로 데이터 전송, HTTP API 설계 시 HTTP 메서드 활용 * 클라이언트 -> 서버 데이터 전달 방식 클라이언트에서 서버로 데이터를 전송하는 방식으로는 쿼리 파라미터를 통한 전송(GET) / 메시지 바디를 통한 전송(GET 외에) 두가지가 있다. - 정적 데이터 조회 이미지나 정적 텍스트 문서와 같은 정적 데이터를 조회할 때에는 단순히 URI의 리소스 경로만으로 조회 가능하다. 즉, GET메서드를 통해 조회하지만 쿼리 파라미터를 통한 데이터 전송을 할 필요가 없다. - 동적 데이터 조회 쿼리 파라미터를 사용해서 데이터를 전달. 서버는 쿼리 파라미터를 기반으로 결과를 동적으로 생성한다. 주로 검색어를 통해 조회 조건을 줄여주는 필터나, 조회 결과를 정렬하는 조건에서 사용된다. 어쨌거..

♪ 학습 내용 HTTP API 개발 및 HTTP 메서드 * URI 설계 처음 URI 설계 시에는 많은 사람들이 다음과 같이 설계하고는 한다. 회원 목록 조회 = /read-member-list 회원 등록 = /create-member 위 설계는 동사, 행위로 URI를 식별하고 있다. read 인지 create인지 delete인지 등등. (좋은 방법이 아니다.) 가장 좋은 방법은 리소스로 식별하는 것. 동사가 아닌 명사로 식별. '미네랄을 캐라' 에서 '캐라' 가 아닌 '미네랄' 이 리소스. 위의 설계에서 리소스는 '회원', member 이다. 때문에 동사는 다 배제하고 명사인 리소스만으로 URI에 매핑해 식별해야 한다. [ 리소스: 회원 ] / [ 행위: 조회, 등록, 삭제, 변경 ] 로 나눠짐. 그렇다..

♪ 학습 내용 HTTP의 기본 특성 * HTTP(Hyper Text Transfer Protocol) 현재 HTTP의 버전은 3까지 있고 주로 1.1 / 2 / 3 버전을 사용. 가장 중요한 것은 HTTP/1.1 이고 HTTP/2 와 HTTP/3 은 이를 개선시킨 것이다. 1.1과 2 버전은 TCP프로토콜 위에서, 3버전은 UDP프로토콜 위에서 동작한다. 앞에서 학습했듯이 TCP는 3-wayhandshake 로 비교적 느리고, UDP레벨에서 성능을 최적화 한 것이 바로 3버전. HTTP는 다음과 같은 특징을 지녔다. - 클라이언트 서버구조 - 무상태 프로토콜( stateless ) - 비연결성 - HTTP 메시지 * HTTP - 클라이언트 서버구조 HTTP는 클라이언트 서버구조이다. 말 그대로 클라이언트..

♪ 학습 내용 URI ( URL , URN ) / 웹의 흐름 * URI(Uniform Resource Identifier) URI는 통합 리소스 식별자이다. 여기서 말하는 리소스는 서버 내 자원으로, URI로 식별할 수 있는 모든 것을 의미함. URI는 큰 개념으로, 로케이터와 이름으로 분류 될 수 있다. 각각의 경우가 바로 URL( locator ) , URN( name ) 주의할 점은 URL과 URN이 아니여도 URI일 수 있다는 점! 두가지로 완전 이분화 되는 것은 아니다! 우리는 흔히 링크 보고 URL 이라고 부르곤 한다. URL은 리소스가 있는 위치를 지정하고, URN은 리소스에 이름을 부여한다. URN 이름만으로 리소스를 활용할 수 있는 방법은 보편화되어있지 않기 때문에 우리는 URI와 URL..

♪ 학습 내용 IP / TCP / UDP / PORT / DNS 컴퓨터는 다음과 같이 복잡한 인터넷 망을 이용하여 통신한다. 이와 관련된 개념들 * IP(인터넷 프로토콜) IP는 IP 주소를 부여해준다. like) 100.100.100.1 IP는 그렇게 지정된 주소에 데이터를 전달. 이때의 단위는 패킷이다. 패킷이란? 패키지(수하물) + 버킷(덩어리) 의 합성어로 전송할 것들을 모아놓은?정도. IP 패킷에는 데이터와 함께 출발지 IP와 목적지IP 등 기타 정보가 담겨있다. 클라이언트에서 서버로, 서버에서 클라이언트로 정보를 주고 받을 때 이 IP패킷을 주고 받는 것. 이러한 IP 프로토콜은 여러 한계를 지니고 있다. 1. 주소를 상대로 데이터를 전송하기 때문에, 대상 서비스가 불능인 경우에도 패킷을 전송..