백엔드 개발 PHP 튜토리얼 Keepalive 및 파이프라인 요청 처리에 대한 nginx 분석

Keepalive 및 파이프라인 요청 처리에 대한 nginx 분석

Aug 08, 2016 am 09:30 AM
keepalive nbsp pipeline request

원본 기사, 재인쇄 시 표시해 주세요: Reprinted from pagefault

이 기사의 링크 주소: keepalive 및 파이프라인 요청 처리에 대한 nginx 분석

이번에는 주로 nginx를 살펴보세요. Keepalive 및 파이프라인 처리와 관련하여 여기에 개념을 소개할 필요가 없습니다. nginx가 어떻게 작동하는지 직접 살펴보겠습니다. 먼저 Keepalive 처리 과정을 살펴보겠습니다. 클라이언트가 명시적으로 연결 헤더를 close로 지정하지 않는 한, keepalive가 http 1.1의 기본값이라는 것을 알고 있습니다. 다음은 keepalive가 필요한지 여부를 결정하는 nginx의 코드입니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

void

ngx_http_handler(ngx_http_request_t *r)

{

.........................................

        switch(r->headers_in.connection_type) {

        case0:

//如果版本大于1.0则默认是keepalive

            r->keepalive = (r->http_version > NGX_HTTP_VERSION_10);

            break;

        caseNGX_HTTP_CONNECTION_CLOSE:

//如果指定connection头为close则不需要keepalive

            r->keepalive = 0;

            break;

        caseNGX_HTTP_CONNECTION_KEEP_ALIVE:

            r->keepalive = 1;

            break;

        }

..................................

}

12 3456789101112131415161718192021
void ngx_http_handler(ngx_http_request_t *r){.... ................................. 스위치(r->headers_in.connection_type) { case 0://버전이 1.0보다 큰 경우 기본값은 연결 유지입니다 r - >keepalive = (r->http_version > NGX_HTTP_VERSION_10);      break; caseNGX_HTTP_CONNECTION_CLOSE://연결 헤더가 close로 지정된 경우 no keepalive가 필요합니다. r->keepalive = 0; break 코드>; 케이스NGX_HTTP_CONNECTION_KEEP_ALIVE: /code>r->keepalive = 1; break;; 코드> }.......... ..... ..}

그러면 keepalive는 현재 http 요청이 실행된 후 바로 현재 연결이 닫히지 않는다는 것을 의미하므로 nginx의 keepalive 관련 처리도 요청 기능을 정리합니다. nginx가 요청을 정리하는 함수는 ngx_http_finalize_request입니다. 이 함수에서는 연결을 해제하기 위해 ngx_http_finalize_connection이 호출되며, keepalive에 대한 관련 판단이 이 함수에 있습니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

staticvoid

ngx_http_finalize_connection(ngx_http_request_t *r)

{

    ngx_http_core_loc_conf_t  *clcf;

    clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);

.....................................................................

//可以看到如果设置了keepalive,并且timeout大于0,就进入keepalive的处理。

    if(!ngx_terminate

         && !ngx_exiting

         && r->keepalive

         && clcf->keepalive_timeout > 0)

    {

        ngx_http_set_keepalive(r);

        return;

    } elseif(r->lingering_close && clcf->lingering_timeout > 0) {

        ngx_http_set_lingering_close(r);

        return;

    }

    ngx_http_close_request(r, 0);

}

12 34567891011121314151617181920212223
staticvoidngx_http_finalize_connection(ngx_http_request_t *r){ ngx_http_core_loc_conf_t *clcf; clcf = ngx_http_get_module_loc_conf(r, ngx_http_core_module);.......................... ................................. //할 수 있습니다 Keepalive가 설정되고 시간 제한이 0보다 큰 경우 Keepalive 처리가 시작됩니다. if(!ngx_terminate && !ngx_exiting && r->keepalive && clcf->keepalive_timeout > 0) { ngx_http_set_keepalive(r); return; 코드> 코드>} elseif(r->lingering_close && clcf->lingering_timeout > 0) { ngx_http_set_lingering_close(r); 반환; } ngx_http_close_request(r, 0);}
위에서 ngx_http_set_keepalive를 통해 keepalive가 설정되어 있음을 알 수 있습니다. 다음으로 이 기능에 대해 자세히 살펴보겠습니다. 이 함수에서는 파이프라인 요청이 부수적으로 처리되므로 함께 살펴보겠습니다. 먼저 nginx가 클라이언트에서 읽은 데이터에 더 많은 데이터가 포함되어 있다고 가정합니다. 즉, 현재 요청을 구문 분석한 후에도 일부 데이터가 아직 남아 있어 파이프라인 요청으로 간주됩니다. 또 다른 매우 중요한 점은 http_connection입니다. 이전 블로그에서 큰 헤더를 할당해야 할 경우 hc->free에서 먼저 가져온 다음 생성된다는 것을 알고 있습니다. hc->busy를 관리하도록 하세요. 그리고 이 buf는 여기서 재사용됩니다. 왜냐하면 큰 buf가 크면 두 번째로 다시 할당해야 하기 때문입니다. 여기서 buf를 재사용하면 할당이 하나 줄어듭니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

    hc = r->http_connection;

    b = r->header_in;

//一般情况下,当解析完header_in之后,pos会设置为last。也就是读取到的数据刚好是一个完整的http请求.当pos小于last,则说明可能是一个pipeline请求。

    if(b->pos < b->last) {

        /* the pipelined request */

        if(b != c->buffer) {

            /*

             * If the large header buffers were allocated while the previous

             * request processing then we do not use c->buffer for

             * the pipelined request (see ngx_http_init_request()).

             *

             * Now we would move the large header buffers to the free list.

             */

            cscf = ngx_http_get_module_srv_conf(r, ngx_http_core_module);

//如果free为空,则新建

            if(hc->free== NULL) {

//可以看到是large_client_headers的个数

                hc->free= ngx_palloc(c->pool,

                  cscf->large_client_header_buffers.num * sizeof(ngx_buf_t *));

                if(hc->free== NULL) {

                    ngx_http_close_request(r, 0);

                    return;

                }

            }

//然后清理当前的request的busy

            for(i = 0; i < hc->nbusy - 1; i++) {

                f = hc->busy[i];

                hc->free[hc->nfree++] = f;

                f->pos = f->start;

                f->last = f->start;

            }

//保存当前的header_in buf,以便与下次给free使用。

            hc->busy[0] = b;

            hc->nbusy = 1;

        }

    }

다음 부분은 무료 요청 및 연결 유지 타이머 설정입니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

    r->keepalive = 0;

    ngx_http_free_request(r, 0);

    c->data = hc;

//设置定时器

    ngx_add_timer(rev, clcf->keepalive_timeout);

//然后设置可读事件

    if(ngx_handle_read_event(rev, 0) != NGX_OK) {

        ngx_http_close_connection(c);

        return;

    }

    wev = c->write;

    wev->handler = ngx_http_empty_handler;

12 3

4

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

    if(b->pos < b->last) {

        ngx_log_debug0(NGX_LOG_DEBUG_HTTP, c->log, 0, "pipelined request");

#if (NGX_STAT_STUB)

        (void) ngx_atomic_fetch_add(ngx_stat_reading, 1);

#endif

//设置标记。

        hc->pipeline = 1;

        c->log->action = "reading client pipelined request line";

//然后扔进post queue,继续进行处理.

        rev->handler = ngx_http_init_request;

        ngx_post_event(rev, &ngx_posted_events);

        return;

    }

56789 10 1112131415
r->keepalive = 0;ngx_http_free_request(r, 0); c->data = hc;//타이머 설정ngx_add_timer(rev, clcf ->keepalive_timeout);//읽을 수 있는 이벤트를 설정합니다if (ngx_handle_read_event(rev, 0) != NGX_OK) {ngx_http_close_connection(c); 반환 ;wev = c->write;wev->handler = ngx_http_empty_handler; 그런 다음 다음 부분은 파이프라인 처리입니다.
12 3456789101112131415 if(b->pos < b->last) {ngx_log_debug0( NGX_LOG_DEBUG_HTTP, c->로그, 0, "파이프라인 요청");#if (NGX_STAT_STUB) (void) ngx_atomic_fetch_add(ngx_stat_reading, 1);#endif//태그를 설정합니다. hc->파이프라인 = 1;c->로그->액션 = "클라이언트 파이프라인 요청 라인 읽기";//그런 다음 게시 대기열에 넣고 처리를 계속합니다. code >rev->handler = ngx_http_init_request;ngx_post_event(rev, &ngx_posted_events);반환; 이 맨 아래에 도달하면 파이프라인 요청이 아니라는 뜻이므로 요청과 http_connection 정리를 시작합니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

    if(ngx_pfree(c->pool, r) == NGX_OK) {

        hc->request = NULL;

    }

    b = c->buffer;

    if(ngx_pfree(c->pool, b->start) == NGX_OK) {

        /*

         * the special note for ngx_http_keepalive_handler() that

         * c->buffer's memory was freed

         */

        b->pos = NULL;

    } else{

        b->pos = b->start;

        b->last = b->start;

    }

.....................................................................

    if(hc->busy) {

        for(i = 0; i < hc->nbusy; i++) {

            ngx_pfree(c->pool, hc->busy[i]->start);

            hc->busy[i] = NULL;

        }

        hc->nbusy = 0;

    }

12 3

4

1

2

3

4

5

6

7

8

9

//后面会详细分析这个函数

    rev->handler = ngx_http_keepalive_handler;

    if(wev->active && (ngx_event_flags & NGX_USE_LEVEL_EVENT)) {

        if(ngx_del_event(wev, NGX_WRITE_EVENT, 0) != NGX_OK) {

            ngx_http_close_connection(c);

            return;

        }

    }

567891011121314151617181920212223 24252627282930
if(ngx_pfree(c->pool, r) == NGX_OK) { hc->request = NULL; } b = c->buffer; if(ngx_pfree (c->풀, b->시작) == NGX_OK) {   /* * ngx_http_keepalive_handler()에 대한 특별 참고 사항 * c->버퍼의 메모리가 해제되었습니다 코드> 코드> */ b->pos = NULL; 코드> } else{    b->pos = b->start; code>else code><code> b->last = b->start; }.......................... ......... ................................ if(hc->busy) {    for code>(i = 0; i < hc->nbusy; i++) {    ngx_pfree(c->pool, hc->busy[i] ->start); hc->busy[i] = NULL; } hc->nbusy = 0; <code>}
Keepalive 처리기를 설정합니다.
12 3456789 //이 함수는 나중에 자세히 분석할 예정입니다. rev->handler = ngx_http_keepalive_handler ; if(wev->active && (ngx_event_flags & NGX_USE_LEVEL_EVENT)) { if(ngx_del_event(wev, NGX_WRITE_EVENT, 0) != NGX_OK) { code><code>ngx_http_close_connection(c);    return; } }
마지막 단계는 tcp push 처리입니다. 지금은 여기서 소개하지 않겠습니다. 다음으로 nginx의 tcp push 동작을 소개하는 특별한 블로그를 준비하겠습니다. 그런 다음 ngx_http_keepalive_handler 함수를 살펴보겠습니다. 이 함수는 연결에 다시 읽을 수 있는 이벤트가 있을 때 호출됩니다. 이 핸들러는 비교적 간단합니다. 새 buf를 생성한 다음 http 요청 실행을 다시 시작합니다(ngx_http_init_request 호출).

그런 다음 데이터가 있으면 읽어 보십시오. 읽을 수 있는 데이터가 없으면 읽기 가능한 이벤트에 핸들이 다시 추가됩니다

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

    b = c->buffer;

    size = b->end - b->start;

    if(b->pos == NULL) {

        /*

         * The c->buffer's memory was freed by ngx_http_set_keepalive().

         * However, the c->buffer->start and c->buffer->end were not changed

         * to keep the buffer size.

         */

//重新分配buf

        b->pos = ngx_palloc(c->pool, size);

        if(b->pos == NULL) {

            ngx_http_close_connection(c);

            return;

        }

        b->start = b->pos;

        b->last = b->pos;

        b->end = b->pos + size;

    }

12 3

4

1

2

3

4

5

6

7

8

9

n = c->recv(c, b->last, size);

c->log_error = NGX_ERROR_INFO;

if(n == NGX_AGAIN) {

    if(ngx_handle_read_event(rev, 0) != NGX_OK) {

        ngx_http_close_connection(c);

    }

    return;

}

567

1

ngx_http_init_request(rev);

89101112131415161718192021
 b = c->버퍼; 크기 = b->end - b->start; 코드> 코드> if(b->pos == NULL) { /* * c->버퍼의 메모리는 ngx_http_set_keepalive()에 의해 해제되었습니다. * 단, c->buffer->start와 c->buffer->end는 변경되지 않았습니다.                                                                                                                                                             code>//buf 재할당 b->pos = ngx_palloc(c->pool, size) ; code><code> if(b->pos == NULL) { ngx_http_close_connection(c);                                                                                              } b->start = b->pos;                                                                                                                                                >위치 + 크기 }
table>드디어 데이터를 읽어오면 요청 처리에 들어갑니다.
1234 56789 n = c->recv(c, b->마지막, 크기); code>c->log_error = NGX_ERROR_INFO;if(n == NGX_AGAIN) { if(ngx_handle_read_event(rev, 0 ) != NGX_OK) { ngx_http_close_connection(c); } 반환;}
1 ngx_http_init_request(rev);
마지막으로 ngx_http_init_request 함수를 살펴보겠습니다. 이번에는 파이프라인이 요청될 때 nginx가 요청을 재사용하는 방법을 주로 살펴보겠습니다.
여기에서 hc->busy[0]에 주의하세요. 파이프라인 요청인 경우 이전에 구문 분석되지 않은 요청 header_in을 저장한다는 것을 이미 알고 있습니다. 이는 두 번째 헤더를 읽었을 수 있기 때문입니다. 파이프라인 요청의 일부 헤더입니다.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

//取得request,这里我们知道,在pipeline请求中,我们会保存前一个request.

    r = hc->request;

    if(r) {

//如果存在,则我们重用前一个request.

        ngx_memzero(r, sizeof(ngx_http_request_t));

        r->pipeline = hc->pipeline;

//如果nbusy存在

        if(hc->nbusy) {

//则保存这个header_in,然后下面直接解析。

            r->header_in = hc->busy[0];

        }

    } else{

        r = ngx_pcalloc(c->pool, sizeof(ngx_http_request_t));

        if(r == NULL) {

            ngx_http_close_connection(c);

            return;

        }

        hc->request = r;

    }

//保存请求

    c->data = r;

12 3

4

567891011121314151617181920212223 2425
//요청 가져오기, 여기서 우리는 파이프라인 요청에서 이전 요청을 저장할 것이라는 것을 알고 있습니다.<code> r = hc->request; if code >(r) {//존재하는 경우 이전 요청을 재사용합니다. ngx_memzero(r, sizeof(ngx_http_request_t)); r->pipeline = hc-> 파이프라인;//nbusy가 존재하는 경우 if(hc ->nbusy) {//이 header_in을 저장한 후 바로 아래에서 구문 분석합니다. r->header_in = hc->busy[0]; 코드> 코드>} } else{ r = ngx_pcalloc(c->pool, 크기(ngx_http_request_t)); if(r == NULL) { ngx_http_close_connection(c); 반환; } hc->request = r; }//요청 저장 c->data = r;
위 코드와 이전 블로그를 통해 큰 헤더가 주로 파이프라인용이라는 것을 알 수 있습니다. 왜냐하면 파이프라인에서는 이전 요청이 다음 요청보다 더 많이 읽는 경우 헤더가 몇 개 있는 경우이기 때문입니다. , 다음 번에 구문 분석할 때 원래 할당된 client_header_buffer_size를 초과할 수 있습니다. 이때 큰 헤더인 헤더를 재할당해야 하므로 여기서 httpconnection은 주로 파이프라인 상황을 위한 것이며 Keepalive 연결이 다음과 같은 경우입니다. 파이프라인 요청이 아닙니다. 메모리를 절약하기 위해 이전 요청이 해제됩니다. 위 내용은 관련 측면을 포함하여 keepalive 및 파이프라인 요청 처리에 대한 nginx의 분석을 소개합니다. PHP 튜토리얼에 관심이 있는 친구들에게 도움이 되기를 바랍니다.
본 웹사이트의 성명
본 글의 내용은 네티즌들의 자발적인 기여로 작성되었으며, 저작권은 원저작자에게 있습니다. 본 사이트는 이에 상응하는 법적 책임을 지지 않습니다. 표절이나 침해가 의심되는 콘텐츠를 발견한 경우 admin@php.cn으로 문의하세요.

핫 AI 도구

Undresser.AI Undress

Undresser.AI Undress

사실적인 누드 사진을 만들기 위한 AI 기반 앱

AI Clothes Remover

AI Clothes Remover

사진에서 옷을 제거하는 온라인 AI 도구입니다.

Undress AI Tool

Undress AI Tool

무료로 이미지를 벗다

Clothoff.io

Clothoff.io

AI 옷 제거제

AI Hentai Generator

AI Hentai Generator

AI Hentai를 무료로 생성하십시오.

인기 기사

R.E.P.O. 에너지 결정과 그들이하는 일 (노란색 크리스탈)
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 최고의 그래픽 설정
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 아무도들을 수없는 경우 오디오를 수정하는 방법
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌
R.E.P.O. 채팅 명령 및 사용 방법
4 몇 주 전 By 尊渡假赌尊渡假赌尊渡假赌

뜨거운 도구

메모장++7.3.1

메모장++7.3.1

사용하기 쉬운 무료 코드 편집기

SublimeText3 중국어 버전

SublimeText3 중국어 버전

중국어 버전, 사용하기 매우 쉽습니다.

스튜디오 13.0.1 보내기

스튜디오 13.0.1 보내기

강력한 PHP 통합 개발 환경

드림위버 CS6

드림위버 CS6

시각적 웹 개발 도구

SublimeText3 Mac 버전

SublimeText3 Mac 버전

신 수준의 코드 편집 소프트웨어(SublimeText3)

해결 방법: 조직에서 PIN 변경을 요구합니다. 해결 방법: 조직에서 PIN 변경을 요구합니다. Oct 04, 2023 pm 05:45 PM

로그인 화면에 "귀하의 조직에서 PIN 변경을 요구합니다"라는 메시지가 나타납니다. 이는 개인 장치를 제어할 수 있는 조직 기반 계정 설정을 사용하는 컴퓨터에서 PIN 만료 제한에 도달한 경우 발생합니다. 그러나 개인 계정을 사용하여 Windows를 설정하는 경우 이상적으로는 오류 메시지가 나타나지 않습니다. 항상 그런 것은 아니지만. 오류가 발생한 대부분의 사용자는 개인 계정을 사용하여 신고합니다. 조직에서 Windows 11에서 PIN을 변경하도록 요청하는 이유는 무엇입니까? 귀하의 계정이 조직과 연결되어 있을 수 있으므로 이를 확인하는 것이 기본 접근 방식입니다. 도메인 관리자에게 문의하면 도움이 될 수 있습니다! 또한 잘못 구성된 로컬 정책 설정이나 잘못된 레지스트리 키로 인해 오류가 발생할 수 있습니다. 지금 바로

Windows 11에서 창 테두리 설정을 조정하는 방법: 색상 및 크기 변경 Windows 11에서 창 테두리 설정을 조정하는 방법: 색상 및 크기 변경 Sep 22, 2023 am 11:37 AM

Windows 11은 신선하고 우아한 디자인을 전면에 내세웠습니다. 현대적인 인터페이스를 통해 창 테두리와 같은 미세한 세부 사항을 개인화하고 변경할 수 있습니다. 이 가이드에서는 Windows 운영 체제에서 자신의 스타일을 반영하는 환경을 만드는 데 도움이 되는 단계별 지침을 설명합니다. 창 테두리 설정을 변경하는 방법은 무엇입니까? +를 눌러 설정 앱을 엽니다. Windows개인 설정으로 이동하여 색상 설정을 클릭합니다. 색상 변경 창 테두리 설정 창 11" Width="643" Height="500" > 제목 표시줄 및 창 테두리에 강조 색상 표시 옵션을 찾아 옆에 있는 스위치를 토글합니다. 시작 메뉴 및 작업 표시줄에 강조 색상을 표시하려면 시작 메뉴와 작업 표시줄에 테마 색상을 표시하려면 시작 메뉴와 작업 표시줄에 테마 표시를 켭니다.

Windows 11에서 제목 표시줄 색상을 변경하는 방법은 무엇입니까? Windows 11에서 제목 표시줄 색상을 변경하는 방법은 무엇입니까? Sep 14, 2023 pm 03:33 PM

기본적으로 Windows 11의 제목 표시줄 색상은 선택한 어두운/밝은 테마에 따라 다릅니다. 그러나 원하는 색상으로 변경할 수 있습니다. 이 가이드에서는 이를 변경하고 데스크톱 환경을 개인화하여 시각적으로 매력적으로 만드는 세 가지 방법에 대한 단계별 지침을 논의합니다. 활성 창과 비활성 창의 제목 표시줄 색상을 변경할 수 있습니까? 예, 설정 앱을 사용하여 활성 창의 제목 표시줄 색상을 변경하거나 레지스트리 편집기를 사용하여 비활성 창의 제목 표시줄 색상을 변경할 수 있습니다. 이러한 단계를 알아보려면 다음 섹션으로 이동하세요. Windows 11에서 제목 표시줄 색상을 변경하는 방법은 무엇입니까? 1. 설정 앱을 사용하여 +를 눌러 설정 창을 엽니다. Windows"개인 설정"으로 이동한 다음

Windows 11/10 복구의 OOBELANGUAGE 오류 문제 Windows 11/10 복구의 OOBELANGUAGE 오류 문제 Jul 16, 2023 pm 03:29 PM

Windows Installer 페이지에 "OOBELANGUAGE" 문과 함께 "문제가 발생했습니다."가 표시됩니까? 이러한 오류로 인해 Windows 설치가 중단되는 경우가 있습니다. OOBE는 즉시 사용 가능한 경험을 의미합니다. 오류 메시지에서 알 수 있듯이 이는 OOBE 언어 선택과 관련된 문제입니다. 걱정할 필요가 없습니다. OOBE 화면 자체에서 레지스트리를 편집하면 이 문제를 해결할 수 있습니다. 빠른 수정 – 1. OOBE 앱 하단에 있는 “다시 시도” 버튼을 클릭하세요. 그러면 더 이상의 문제 없이 프로세스가 계속됩니다. 2. 전원 버튼을 사용하여 시스템을 강제 종료합니다. 시스템이 다시 시작된 후 OOBE가 계속되어야 합니다. 3. 인터넷에서 시스템 연결을 끊습니다. 오프라인 모드에서 OOBE의 모든 측면을 완료하세요.

Windows 11에서 작업 표시줄 축소판 미리 보기를 활성화 또는 비활성화하는 방법 Windows 11에서 작업 표시줄 축소판 미리 보기를 활성화 또는 비활성화하는 방법 Sep 15, 2023 pm 03:57 PM

작업 표시줄 축소판은 재미있을 수도 있지만 주의를 산만하게 하거나 짜증나게 할 수도 있습니다. 이 영역 위로 얼마나 자주 마우스를 가져가는지 고려하면 실수로 중요한 창을 몇 번 닫았을 수도 있습니다. 또 다른 단점은 더 많은 시스템 리소스를 사용한다는 것입니다. 따라서 리소스 효율성을 높일 수 있는 방법을 찾고 있다면 비활성화하는 방법을 알려드리겠습니다. 그러나 하드웨어 사양이 이를 처리할 수 있고 미리 보기가 마음에 들면 활성화할 수 있습니다. Windows 11에서 작업 표시줄 축소판 미리 보기를 활성화하는 방법은 무엇입니까? 1. 설정 앱을 사용하여 키를 탭하고 설정을 클릭합니다. Windows에서는 시스템을 클릭하고 정보를 선택합니다. 고급 시스템 설정을 클릭합니다. 고급 탭으로 이동하여 성능 아래에서 설정을 선택합니다. "시각 효과"를 선택하세요.

Windows 11의 디스플레이 크기 조정 가이드 Windows 11의 디스플레이 크기 조정 가이드 Sep 19, 2023 pm 06:45 PM

Windows 11의 디스플레이 크기 조정과 관련하여 우리 모두는 서로 다른 선호도를 가지고 있습니다. 큰 아이콘을 좋아하는 사람도 있고, 작은 아이콘을 좋아하는 사람도 있습니다. 그러나 올바른 크기 조정이 중요하다는 점에는 모두가 동의합니다. 잘못된 글꼴 크기 조정이나 이미지의 과도한 크기 조정은 작업 시 생산성을 저하시킬 수 있으므로 시스템 기능을 최대한 활용하려면 이를 사용자 정의하는 방법을 알아야 합니다. Custom Zoom의 장점: 화면의 텍스트를 읽기 어려운 사람들에게 유용한 기능입니다. 한 번에 화면에서 더 많은 것을 볼 수 있도록 도와줍니다. 특정 모니터 및 응용 프로그램에만 적용되는 사용자 정의 확장 프로필을 생성할 수 있습니다. 저사양 하드웨어의 성능을 향상시키는 데 도움이 될 수 있습니다. 이를 통해 화면의 내용을 더 효과적으로 제어할 수 있습니다. 윈도우 11을 사용하는 방법

Windows 11에서 밝기를 조정하는 10가지 방법 Windows 11에서 밝기를 조정하는 10가지 방법 Dec 18, 2023 pm 02:21 PM

화면 밝기는 최신 컴퓨팅 장치를 사용할 때 필수적인 부분이며, 특히 화면을 장시간 볼 때 더욱 그렇습니다. 눈의 피로를 줄이고, 가독성을 높이며, 콘텐츠를 쉽고 효율적으로 보는 데 도움이 됩니다. 그러나 설정에 따라 밝기 관리가 어려울 수 있으며, 특히 새로운 UI 변경이 적용된 Windows 11에서는 더욱 그렇습니다. 밝기를 조정하는 데 문제가 있는 경우 Windows 11에서 밝기를 관리하는 모든 방법은 다음과 같습니다. Windows 11에서 밝기를 변경하는 방법 [10가지 설명] 단일 모니터 사용자는 다음 방법을 사용하여 Windows 11에서 밝기를 조정할 수 있습니다. 여기에는 단일 모니터를 사용하는 데스크탑 시스템과 노트북이 포함됩니다. 시작하자. 방법 1: 알림 센터 사용 알림 센터에 액세스할 수 있습니다.

Windows Server에서 활성화 오류 코드 0xc004f069를 수정하는 방법 Windows Server에서 활성화 오류 코드 0xc004f069를 수정하는 방법 Jul 22, 2023 am 09:49 AM

Windows의 정품 인증 프로세스에서 갑자기 이 오류 코드 0xc004f069가 포함된 오류 메시지가 표시되는 경우가 있습니다. 활성화 프로세스가 온라인으로 진행되더라도 Windows Server를 실행하는 일부 이전 시스템에서 이 문제가 발생할 수 있습니다. 이러한 초기 점검을 수행하고 시스템 활성화에 도움이 되지 않으면 기본 해결 방법으로 이동하여 문제를 해결하십시오. 해결 방법 - 오류 메시지와 활성화 창을 닫습니다. 그런 다음 컴퓨터를 다시 시작하십시오. Windows 정품 인증 프로세스를 처음부터 다시 시도하세요. 수정 1 – 터미널에서 활성화 cmd 터미널에서 Windows Server Edition 시스템을 활성화합니다. 1단계 – Windows Server 버전 확인 현재 사용하고 있는 W 종류를 확인해야 합니다.

See all articles