앞에서 살펴본 em과 rem은 주변 상황에 따라 그 크기를 달리할 수 있는 가변성을 지니고 있지만, 브라우저나 기기 화면에 크기에 따라 크기가 달라지는 단위는 아니다. 따라서 진정한 반응형 단위라고 할 수 는 없다.

 

 

반응하는 단위들 

아래 몇 가지 단위들은 뷰포트 크기를 기반으로 값을 계산하여 크기를 결정하는 가변 단위이다.

font-size: 1vw; /* 뷰포트 너비의 100분의 1 */
font-size: 1vh; /* 뷰포트 높이의 100분의 1 */

/* 뷰포트 높이와 너비 중 작은 쪽의 100분의 1 */
font-size: 1vmin;

/* 뷰포트 높이와 너비 중 큰 쪽의 100분의 1 */
font-size: 1vmax;

 

사용해보자

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>다른 상대 단위들</title>
    <style>
        p{
            margin: 0;
            font-size: 50vw;
        }

    </style>
</head>
<body>
    <p>왕왕</p>
</body>
</html>

 

위 소스를 확인해보면 

 

브라우저의 크기에 따라 글씨의 크기가 달라지는 것을 확인할 수 있다.

 

뷰포트 높이로 설정을 변경해보자

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta http-equiv="X-UA-Compatible" content="IE=edge">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>다른 상대 단위들</title>
    <style>
        p{
            margin: 0;
            font-size: 50vh;
        }

    </style>
</head>
<body>
    <p>왕왕</p>
</body>
</html>

 

 

 

이제는 넓이에는 영향을 받지 않는다.

 

브라우저 창의 높이를 줄이면 글씨가 작아지게 된다.

 

 

정리

 

'Front-End > 반응형 웹' 카테고리의 다른 글

반응형 웹(6) - 미디어 쿼리  (0) 2024.07.17
반응형 웹(5) - calc()  (0) 2024.07.15
반응형 웹(4) - 가변형 레이아웃  (2) 2024.07.14
반응형 웹(2) em & rem  (0) 2024.07.09
반응형 웹(1)  (0) 2024.07.08

CPU가 메모리에 접근하는 시간은 CPU 연산 속도보다 현저하게 느리다. 이것을 어떻게 해결할 수 있을까?

CPU 메모리 접근

 

저장 장치 계층 구조

  1. CPU와 가까운 저장 장치는 빠르고, 멀리 있는 저장 장치는 느리다.
  2. 속도가 빠른 저장 장치는 저장 용량이 작고, 가격이 비싸다.

 

저장 장치들은 'CPU에 얼마나 가까운가'를 기준으로 계층적으로 나타낼 수 있다.

저장 장치 계층 구조

 

캐시 메모리

  • CPU와 메모리 사이에 위치한, 레지스터보다 용량이 크고 메모리보다 빠른 SRAM 기반의 저장 장치
  • CPU의 연산 속도와 메모리 접근 속도의 차이를 조금이나마 줄이기 위해 탄생한 저장 장치이다.
  • CPU가 매번 메모리에 왔다 갔다 하는 건 시간이 오래 걸리기 때문에, 메모리에서 CPU가 사용할 일부 데이터를 미리 캐시 메모리로 가지고 와서 사용한다.

캐시 메모리는 편의점에 비유할 수 있다

 

캐시 메모리를 사용하는 경우

 

계층적 캐시 메모리(L1-L2-L3 캐시)

계층적 캐시 메모리

 

 

멀티코어 프로세서의 캐시 메모리

멀티코어 프로세서의 캐시 메모리

 

코어마다 따로 캐시를 가질 수 있고, 공유하는 캐시 메모리를 갖는다.

 

 

분리형 캐시

분리형 캐시

 

조금 더 속도를 빠르게 하기 위해 L1 캐시를 분리한 캐시이다. ex) L1D -> 데이터만 저장, L1l -> 명령어만 저장

 

 

 

참조 지역성의 원리

캐시 메모리는 메모리보다 용량이 작다. 당연하게도 메모리의 모든 내용을 저장할 수 없다.

그렇다면 무엇을 저장해야 할까? 

 

CPU가 자주 사용할 법한 내용을 예측하여 저장한다.

 

예측이 들어맞을 경우 (CPU가 캐시 메모리에 저장된 값을 활용한 경우) = 캐시 히트 라고 한다.

예측이 틀렸을 경우 (CPU가 메모리에 접근해야 하는 경우) = 캐시 미스 라고 한다.

 

 

캐시 적중률 

캐시 적중률

캐시 적중률이 높아야 한다. 

 

참조 지역성의 원리는 CPU가 메모리에 접근할 때의 주된 경향을 바탕으로 만들어진 원리이다. 

  1. CPU는 최근에 접근했던 메모리 공간에 다시 접근하려는 경향이 있다.
  2. CPU는 접근한 메모리 공간 근처를 접근하려는 경향이 있다.

 

공간 지역성 예시

 

 

'컴퓨터구조와 운영체제' 카테고리의 다른 글

RAID 정의와 종류  (0) 2024.08.08
보조기억장치  (1) 2024.07.20
메모리의 주소 공간  (0) 2024.07.07
RAM의 특성과 종류  (1) 2024.07.03
명령어 집합 구조  (2) 2024.07.02

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다. 이 데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다. 이 메시지는 클라이언트, 서버, 프락시 사이를 흐른다.

 

'인바운드', '아웃바운드', '업스트림', '다운스트림'은 메시지의 방향을 의미하는 용어이다.

 

메시지는 원 서버 방향을 인바운드로 하여 송신된다

HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용한다. 메시지가 원 서버로 향하는 것은 인바운드로 이동한느 것이고, 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것이다.

원 서버로 인바운드로 이동하고 클라이언트로 아웃바운드로 복귀하는 메시지

 

 

다운스트림으로 흐르는 메시지

HTTP 메시지는 강물과 같이 흐른다. 요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다. 메시지의 발송자는 수신자의 업스트림이다.

메시지는 다운스트림으로 흐른다.

 

 

메시지의 각 부분

HTTP 메시지는 단순한, 데이터의 구조화된 블록이다. 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함한다. 메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다. 시작줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있으며, 본문은 아예 없을 수도 있다.

HTTP 메시지의 세 부분

 

 

시작줄 

모든 HTTP 메시지는 시작줄로 시작한다. 요청 메시지의 시작줄은 무엇을 해야 하는지 말해준다. 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.

 

요청줄

요청 메시지는 서버에게 리소스에 대해 무언가를 해달라고 부탁한다. 요청 메시지의 시작줄, 혹은 요청줄에는 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 그 동작에 대한 대상을 지칭하는 요청 URL이 들어있다. 또한 요청줄은 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에 알려주는 HTTP 버전도 포함한다.

요청과 응답 메시지 예시

 

 이 모든 필드는 공백으로 구분된다. 위 그림에서 요청 메서드는 GET이고, 요청 URL은 /test/hi-there.txt 이며, 버전은 HTTP/1.1이다. 

 

 

응답줄

응답 메시지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다. 응답 메시지의 시작줄 혹은 응답줄에는 응답 메시지에서 쓰인 HTTP의 버전, 숫자로 된 상태 코드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있다.

이 모든 필드는 공백으로 구분된다. 위 그림에서 HTTP 버전은 HTTP/1.0이고, 상태 코드는 200(성공)이며, 사유 구절은 OK로 문서가 성공적으로 반환되었음을 의미한다.

 

 

메서드

요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해준다. 예를 들어, 'GET/specials/saw-blase.gif HTTP/1.0' 이라는 줄에서 메서드는 GET이다.

많이 쓰이는 HTTP 메서드

 

 

 

상태 코드

메서드가 서버에게 무엇을 해야 하는지 말해주는 것처럼, 상태 코드는 클라이언트에게 무엇이 일어났는지 말해준다. 상태 코드는 응답의 시작줄에 위치한다. 예를 들어, 'HTTP/1.0 200 OK'라는 줄에서 상태 코드는 200이다.

상태 코드의 종류

 

많이 쓰이는 상태 코드

 

 

 

GET 

GET은 가장 흔히 쓰이는 메서드다. 주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다. 

GET 예시

 

HEAD

HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다. 엔터티 본문은 결코 반환되지 않는다. 이는 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해준다. HEAD를 사용하면,

  • 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
  • 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
  • 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 한다.

HEAD 예시

 

 

PUT

GET 메서드가 서버로부터 문서를 읽어 들이는데 반해 PUT 메서드는 서버에 문서를 쓴다. 어떤 발행 시스템은 사용자가 PUT을 이용해 웹페이지를 만들고 웹 서버에 직접 게시할 수 있도록 해준다.

PUT 예시

PUT 메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다. PUT은 콘텐츠를 변경할 수 있게 해주기 때문에, 많은 웹 서버가 PUT을 수행하기 전에 사용자에게 비밀번호를 입력하여 로그인을 하도록 요구할 것이다.

 

 

POST

POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다. 실제로, HTML 폼을 지원하기 위해 흔히 사용된다. 채워진 폼에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는 곳에 보낸다. 

POST 예시

 

 

+ Recent posts